Finality is one of the key properties of public ledger blockchains. Unlike traditional financial networks, finality in blockchain networks describes an irreversible state. When a block of transactions is added to a blockchain, it is expected to remain for eternity. The deeper a block is in the chain, the more work would be required to reverse any transactions; this design financially disincentivizes transaction reversal for network participants thus making it *highly improbable*. Prior to final block inclusion, a majority of nodes in the network must agree that the current chain is valid before adding a new block to it. Hence, there is always a possibility that nodes could disagree and splinter off in a competing chain. > [!quote] We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker. Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them. ~ [[@Satoshi Nakamoto]] in the [[Bitcoin Whitepaper.pdf|Bitcoin Whitepaper (PDF)]]. This is where a [[51% Attack]] on the network comes into play. Because a [[Consensus Mechanism|consensus mechanism]] is designed to confirm agreements on the blockchain, the winning chain requires the majority of the [[Hashpower|hashpower]] to achieve, and so the longest chain ultimately wins. The intended effect is that transactions are agreed as valid and final, rejecting all invalid transaction blocks so that there can be no [[Double-spending|double-spending]] on the network. >[!tip] When competing chains occur and finality comes to a halt, the result is typically a blockchain [[Reorgs|reorg]]; ultimately all nodes in the network must agree on a valid chain and "reorg" into that chain. Historically, there have been broader disagreements amongst a blockchain communities on protocol rulesets, which resulted in "contentious" [[Forks#Hard forks|hard forks]]. How chains behave during/after reorgs or forks is largely dependent on the protocol ruleset (i.e., the *type* of finality that chain deploys). ____ ### Probabilistic Finality There are two primary types of finality: probabilistic and deterministic. Probabilistic finality means that as more blocks are added, the chances of prior blocks being reversed due to a reorg become increasingly small. Bitcoin's [[Proof of Work]] consensus mechanism is an example of probabilistic finality. ### Deterministic Finality Deterministic finality guarantees absolute certainty that once a block has been added to the blockchain, it cannot be changed or reversed under any circumstances. This level of assurance makes deterministic finality highly desirable for many applications and is often found in [[Practical Byzantine Fault Toleranc|Practical Byzantine Fault Tolerant]] protocols. ### Single-slot Finality Single-slot finality is a type of deterministic finality, which refers to systems using designated time periods or "slots" to produce exactly one finalized block at a time. In these systems, there's no ambiguity about which version of history is correct since only one valid outcome can exist per slot. >[!example] Example >In Ethereum 2.0, there's an implementation called Casper Friendly Finality Gadget (FFG) which provides immediate block finality; no forks can occur once a block has been validated and finalized. > [For more information, check out the authoritative source](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality). ### Checkpoint Finality Checkpoint finality involves periodically inserting special "checkpoint" blocks into the blockchain at predetermined intervals or conditions. These checkpoint blocks serve as irreversible points in the chain's history; all transactions before this point are considered finalized and [[Immutability|immutable]]. Checkpointing can help improve scalability by reducing the amount of data needed to validate new nodes joining the network. >[!example] Example >In the current Ethereum 2.0 testnets, this mechanism is used. In this implementation, blocks are finalized when they reach checkpoints, which occur every 32 slots (approximately 6.4 minutes). The Beacon Chain follows an LMD GHOST (Latest Message Driven Greediest Heaviest Observed SubTree) fork choice rule and uses Casper FFG for finality > >[For more information, check out the authoritative source](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality).