Editor’s note: This article comes from ChainNews (ID: chainnewscom), the original author: Alexis Gauba, co-founder of Mechanism Labs, compiled by: Zhan Juan, reprinted with authorization.
Today, I swipe my card to buy a refreshing matcha latte. After swiping the card, the store made this drink for me very confidently. The merchant is confident that the transaction has been successful and that the money will not be returned to my card, but into their account. In other words, buying is over. But in fact, credit card transactions are very complicated. Credit card transactions need to be completed within 60 days. Merchants can also accept credit card consumption for small transactions, but for large transactions, they are more willing to accept checks or wire transfers. Only cash transactions can achieve instant finality.
In the blockchain context, finality means that once committed to the blockchain, all well-formed blocks cannot be revoked.When users make a transaction, they expect that once their transaction goes through, the transaction cannot be arbitrarily changed or rolled back. Therefore, finality is of paramount importance when designing blockchain consensus protocols.
A block being revoked could cost millions of dollars, or impact fundamental operations in a decentralized application. Therefore, understanding finality is critical to building robust blockchain platforms and choosing which platforms to develop applications on.
secondary title
Categorize finality
Probabilistic finality refers to the finality provided by blockchain-based protocols, and Bitcoins Nakamoto consensus belongs to this category. In this case, the further down the chain the block containing the transaction is, the greater the probability that the transaction will not be rolled back. The deeper the block, the more likely the fork containing that block is the longest chain. Thats why on the Bitcoin blockchain, we would recommend waiting until a transaction has been confirmed for six blocks before confirming its authenticity, that is, waiting for about an hour before completing the transaction, so that the transaction can be guaranteed The possibility of being rolled back is very low.
Absolute finality refers to the finality provided by protocols based on Practical Byzantine Fault Tolerance PBFT, of which Tendermint is a representative. In this case, transactions are considered final as soon as they are included in a block and added to the blockchain. In this case, the leader will propose a block, and the validating committee needs to reach a majority consensus in approving this block.
secondary title
CAP theorem and finality
While absolute finality may seem preferable to probabilistic finality, there are still some fundamental trade-offs when picking.
Using Eric Brewers CAP Theorem is useful when considering the trade-off between probability and finality based on Byzantine Fault Tolerant BFT.
image description
Left: a system that prefers consistency; right: a system that prefers availability
secondary title
Finality in PoS consensus
Here is our analysis of some major PoS platforms:
Tendermint
Tendermint achieves absolute finality. Any block that receives more than 2/3 of the votes in the pre-vote or pre-commit can achieve instant finalization. This process continues until 1/3 or more of the validators no longer respond positively, in which case the network is momentarily interrupted, showing that Tendermint favors consistency over availability. The protocol also achieves economic finality when applying PoS slashing rules to Tendermint.
Thunderella
Thunderellas fast path provides absolute finality. Any notarized maximum sequence of transactions can be considered a confirmed output. If more than 3/4 of the fast-path committee members are honest and online, and the applicant is also honest, then a valid transaction can be confirmed instantly. However, the fast-path confirmation is different from the finality of the whole, it is a kind of finality under ideal conditions. Once the transaction is recorded on the underlying blockchain, it will be fully confirmed, which can be set up on the chain or based on the BFT algorithm. Thunderella prioritizes usability by pushing to the base blockchain in case the fast path fails.
Algorand
As long as the attacker controls less than 1/3 of the currency value of the protocol, Algorand can guarantee that the probability of a fork is negligible, allowing the protocol to run in a strongly synchronized manner so that each block reaches a final agreement. In weak synchronization, Algorand may fork, but uses Byzantine Agreement BA* to negotiate which fork to choose. This way, transactions in Algorand are finalized when the protocol returns to strong sync. Algorand prioritizes consistency over availability, preferring to generate empty blocks when candidate blocks cannot be accepted.
Ouroboros Genesis
Genesis can achieve probabilistic termination according to its blockchain selection rules. This rule is for short-range up to k blocks, where k is a security parameter, follow the longest chain; for long-range more than k blocks, use the adequacy rule plenitude rule, which means checking the time period immediately after the current chain forks, and Choose a higher density chain.
Casper FFG
Casper FFG aims to provide absolute/economic finality for blockchain-based systems, and blocks can be signed when the committee obtains an absolute majority of more than 2/3 weighted by equity. Casper FFG uses this construction method, even if an attacker controls the proposal mechanism of the underlying blockchain, it is impossible for conflicting checkpoints to be finalized. However, since FFG provides safety and the proposal mechanism provides liveness, an adversary can stall consensus to prevent Casper from finalizing future checkpoints. FFG prioritizes consistency because it does not allow checkpoints to be completed without more than 2/3 of validators agreeing. The FFG also allows for financial closure through a reduction mechanism.
Casper TFG
Casper TFG achieves absolute finality through validators with different fault tolerance thresholds. That is, its protocol is asynchronously safe and Byzantine fault tolerant, allowing validators to have different fault tolerance thresholds.
