# Ensuring things won’t change: Finality. In centralized systems, the entity responsible for updating states also guarantees that changes made do not get reverted. If I upload a picture to iCloud, or a video on YouTube (outside of censorship and account banning), there is the guarantee that my picture or video won’t disappear after a day. This guarantee is trivial to provide by services built around centralized systems. Things are a bit different in decentralized systems. With decentralization, the environment of operation cannot be controlled like centralized systems. Also as initially mentioned, the environment in which decentralized systems like blockchain operates is also quite an adversarial one. The fact that blockchain systems employ peer-to-peer networking also means the way data propagates can be chaotic. The consequence of this, as regards the state of the blockchain is what is often termed reorgs. This is a situation where state updates get reverted as the system comes to a consensus. Reorg means what was previously thought to be the canonical chain by a node, ends up not being the canonical chain as the nodes receive new broadcasted blocks in the network. In such a scenario, the node will have to undo the state updates based upon what was initially thought to be the canonical chain and re-apply the state updates based on the new, up-to-date information it now has about what the canonical chain is. Obviously, a system that cannot guarantee that changes made are permanent cannot be used for any meaningful, real-world purposes. For example, an e-commerce shop needs the guarantee that after payment has been made via their webshop and the product delivered to a customer, no reorg should happen that reverts the payment made. Hence there is a need for blockchain systems to provide a guarantee that changes made are final and cannot be reverted. This guarantee is encoded in finality protocols. Once again, this idea is not peculiar to a single blockchain system, hence we will look at how finality is achieved in Bitcoin, Ethereum, and Polkadot. ### Consensus Protocol In Bitcoin for finality Bitcoin does not have a defined stand-alone protocol for finality, instead, finality is an emergent property of the proof of work-based protocol for selecting block authors and the Nakamoto consensus. The idea is that if a block is part of the canonical chain, that is the longest chain with the highest proof of work, then there is a guarantee that the canonical chain it belongs to will always remain the canonical one. This is because for there to be a re-org, there must be another chain that is longer than the canonical chain. And since it takes effort to produce a block, thanks to the hashing task that needs to be performed, then after a certain height, it becomes economically unfeasible for another chain to be mined at a rate that will make it overtake the current longest canonical chain. Hence if a block is buried deep enough within the canonical chain, then, by all means, it can be considered to be safe from any reverts. Hence in Bitcoin, finality is generally assumed for a block after about 6 new blocks have been added on top of it in the chain. This type of finality is often referred to as probabilistic finality. ### Consensus Protocol In Ethereum for finality Finality in Ethereum is achieved via a well-defined protocol called Casper Friendly Finality Gadget (often referred to as Casper FFG). It is a finality gadget because it does not operate on its own, rather it works atop a block-producing and fork-choice protocol. In the case of Ethereum, the Casper FFG works as an add-on to the LMD-GHOST fork-choice rule. While LMD-GHOST fork-choice rule ensures that the canonical chain can progress, the Casper FFG ensures finality for the progressing canonical chain. Simply put, the Casper FFG works on the mechanism of voting called attestations by validators participating in the network. As mentioned in the section about the fork-choice rule in Ethereum, the protocol as part of its operation selects a subset of nodes that cast votes regarding the validity of messages within the blockchain system. One such voting, as we saw in the fork-choice rule, is attesting that a block produced is correct. Another voting that takes place is the one that ascertains a block, usually called the checkpoint, is part of the canonical chain. This attestation for the checkpoint block happens in two rounds spaced in time. If ⅔ of the validator attests that a block is a checkpoint in both rounds, then all the blocks that make up the chain till the checkpoint block are finalized and will never revert. This type of finality is referred to as provable finality. Which is different from probabilistic finality as obtained with Bitcoin. In Bitcoin we can only estimate the probability that a block is final based on how many more blocks have been built on it. Such finality depends on various assumptions about the network and participants, and how fast or slow the chain is progressing. With Casper, FFG finality is assured once the two rounds of attestation have occurred. Hence why it is called provable finality. ### Consensus Protocol In Polkadot for finality The protocol for ensuring finality in Polkadot is called **G**HOST-based **R**ecursive **AN**cestor **D**eriving **P**refix **A**greement (GRANDPA), and since Polkadot is also a proof of stake blockchain, it works based on the idea of attestation by validators. As earlier mentioned, Polkadot does not have a separate fork-choice rule to resolve forks. Instead, block production continues based on the BABE protocol, even if there is a fork. It is left to the GRANDPA finality protocol to resolve such forks, selects the canonical chain, and also enforces finality. Simply described, GRANDPA works by selecting the canonical chain which is the chain that has the highest number of blocks that was built using the primary VRF-based mechanism in BABE for block production. Once such a chain is identified, the chain is also guaranteed to be finalized, meaning that all blocks up to the tip of the chain are guaranteed not to be reverted. Another way to view this, is that when GRANDPA considers a block valid, it implies that block's parent is also valid, and so on. This strategy makes it possible for GRANDPA to finalize log chains without a network overhead In the image above, the black blocks are finalized, but the yellow blocks are part of the forks from which a canonical chain needs to be picked. Blocks marked with a '1' are primary blocks; that is blocks built with BABE’s VRF mechanism. Those with a "2" are secondary blocks and these are the blocks built with the fallback round-robin algorithm that is used when the VRF mechanism fails to select a block producer. The second fork becomes part of the canonical chain as it has the most primary blocks that build on a previously finalized chain. {% hint style="info" %} * GRANDPA: Block Finality in Polkadot\ {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://geekabyte.gitbook.io/blockchain-protocol-development-guide/ensuring-things-wont-change-finality..md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.