A consensus algorithm is a mechanism to reach agreement among nodes in distributed networks. It removes the need for a central authority and allows the whole network to agree on data and the ordering of events in a trustless way.
Nodes participating in the network maintain an exact copy of the ledger, allowing applications built on top of the consensus protocol to function correctly.
aBFT consensus stands for “asynchronous Byzantine-fault-tolerant” consensus. When a network is said to be Byzantine fault tolerant, it means that nodes can still reach an agreement on an ordering of events even if part of the network acts maliciously.
Asynchronous BFT allows nodes in the network to confirm blocks containing transactions without depending on any timing assumptions. This makes the confirmation of transactions by the network faster, without compromising security or decentralization.
When a transaction is confirmed by the network, it achieves complete finality and cannot be changed or reverted. aBFT consensus reaches agreement on transactions even when some of the messages between nodes are lost, which makes the network more resilient
Blockchains such as Ethereum and Bitcoin are synchronous, meaning that transactions are appended into blocks one at a time. They follow the longest-chain rule in which the chain with the most number of blocks determines the final ordering of events. Transactions in earlier blocks have a much higher probability of being part of the final ordering of events compared to more recent transactions.
Therefore, these networks require multiple confirmations to ensure that a transaction is permanently part of the blockchain. This behavior leads to a slower confirmation of the transactions than in aBFT consensus.
Finality means that a transaction cannot be changed or reversed by any party. aBFT consensus algorithms such as Lachesis have a very low time to finality because they achieve absolute finality. Absolute finality means that a transaction is considered final once it is included in a block.
In the case of Fantom, the Opera Chain can accomplish finality in 1 to 2 seconds. TxFlow can achieve finality in less than a second.
Conversely, Nakamoto consensus protocols rely on probabilistic finality. In this case, the probability that a transaction will not be reverted increases with time. The more blocks that are created on top of a block, thereby confirming it as correct, the more difficult and costlier it would be to revert a transaction in that block. At some point it becomes theoretically impossible to alter older blocks, increasing the probabilistic finality to nearly 100%.
Bitcoin has a finality of 30 to 60 minutes; when using Bitcoin, you have to wait a few block confirmations before considering the transaction final and irreversible. Ethereum has a finality of a few minutes.
TxFlow is an aBFT middleware protocol designed for responsiveness. It runs together with a traditional consensus algorithm such as Lachesis, which guarantees network security.
Fantom has an ERC20 token, but it cannot be used directly on the Opera mainnet.
Here is a breakdown of the different FTM tokens in circulation at the moment
1. Opera FTM: Used on Fantom’s mainnet Opera Chain 2. ERC20: Exists on the Ethereum network 3. BEP2: Exists on Binance Chain
Note that Fantom Opera addresses share the same structure as Ethereum addresses (0x…), but they are not Ethereum addresses.
No. You need to transfer them over to Fantom using a bridge.
The FTM token has a number of use cases within the Fantom ecosystem. It plays an essential role in a well-functioning, healthy network.
1. Securing the network Fantom uses a proof-of-stake system that requires validators to hold FTM. Anyone with at least 500,000 FTM can run their own validator node to earn rewards and secure the network.
Every FTM holder has the option to delegate their tokens to a validator (while keeping full custody of their funds) to receive staking rewards. Validators then take a small fee for their services.
By locking in their FTM, validators help the network to be decentralized and secure.
2. Paying for network fees To compensate validators for their services and prevent transaction spam, every action performed within the Fantom network costs a small fee. This fee is paid in FTM.
3. Voting in on-chain governance Decisions regarding the Fantom ecosystem are made using transparent on-chain voting. Votes are weighted according to the amount of FTM held by an entity. Basically, 1 FTM equals 1 vote.
4. Additional use cases FTM is used to earn APR/APY on many DeFi platforms.
You cannot stake FTM on exchanges at the moment.
To run a validator node on Fantom’s Opera Chain, the following is required:
- 1.A minimum stake of 500,000 FTM;
- 2.AWS EC2 m5.xlarge with 4 vCPUs (3.1 GHz) and at least 1TB of Amazon EBS General Purpose SSD (gp2) storage (or equivalent).
Please note that the above wallet only support Opera Network FTM. They do not support ERC20 or BEP2.
Opera is a fully decentralized blockchain network with smart contract support, and it is Fantom's mainnet. It is compatible with the Ethereum Virtual Machine and powered by Fantom’s aBFT consensus algorithm, Lachesis. Thus, smart contracts developed on Ethereum can run on Opera, with an increase in scalability and security.
Yes. Fantom is fully compatible with the Ethereum Virtual Machine (EVM). It also has Web3JS API and RPC support.
All smart contracts written in Solidity or Vyper, compiled and deployed on Ethereum, are fully compatible with the Opera Network.
Fantom is currently working with both the University of Sydney Programming Languages group, and the Yonsei University Embedded System Languages and Compilers Group, to build a new “Fantom Virtual Machine” (FVM), interpreter, and database to achieve much better performance and security than the EVM. The FVM will be compatible with the Solidity programming language.
Fantom’s Opera network supports all smart contract languages that Ethereum supports for the EVM, which include both Solidity and Vyper.
The Fantom Opera Chain went live on 27 December 2019.
The Fantom Foundation is currently in charge of the governance of the network, advised by the community and validator nodes. We plan to launch a governance smart contract that will allow validators and token holders to determine the direction of Fantom, as well as to approve changes to the underlying consensus via hard and soft forks.