The "consensus layer" is the new layer we added to Ethereum 2.0 with "The Merge". It is otherwise known as the "Beacon Chain". We'll begin by quoting [Ben Edgington's book](https://eth2book.info/latest/part2/consensus/) to give ourselves a grounded sense of what consensus is: 1. **Consensus is a way to build reliable distributed systems with unreliable components**. 2. Blockchain-based distributed systems aim to agree on a single history of transactions. 3. Proof of work and proof of stake are not consensus protocols, but enable consensus protocols. 4. Many blockchain consensus protocols are "forkful". 5. Forkful chains use a fork choice rule, and sometimes undergo reorganisations. 6. In a "safe" protocol, nothing bad ever happens. 7. In a "live" protocol, something good always happens. 8. No practical protocol can be always safe and always live. We have already learnt that there are two approaches to [[1. Execution|Execution]], one of which is a "data availability consensus game". This is basically what we are playing when we separate the consensus layer from the layer on which transactions actually get executed. Since consensus is no longer concerned with transaction validity, verification amounts to checking data availability. That is, validators in the Beacon Chain only check that all the data in a given bundle is actually available: they leave the execution of the transactions (and the associated validity checks) to the execution layer. The checks consensus layer validators perform are done via [data availability sampling](https://www.youtube.com/live/xuLyZaty9iI?t=1388), which (after full danksharding) will allow validators to verify availability without having to download the entire block. ## The Protocol But wait!? Proof of work is not a consensus protocol? Yes, proof of work and proof of stake are [Sybil resistance](https://eth2book.info/bellatrix/part2/incentives/staking#introduction) mechanisms that place a cost on participating in the protocol, which prevents attackers from overwhelming the protocol at low or zero cost. Both proof of work and proof of stake are often fairly tightly coupled, via the [fork choice rule](https://eth2book.info/bellatrix/part2/consensus/preliminaries/#fork-choice-rules), to the consensus mechanisms that they support. They provide a useful way to assign a weight, or a score, to a chain of blocks: in proof of work, the total work done; in proof of stake, the amount of value that supports a particular chain. Both proof of work and proof of stake enable many kinds of different consensus protocols to be built on them, each with its own trade-offs. For instance, the consensus protocol in Ethereum 2 "bolts together" two different consensus protocols. One is called [Casper FFG](https://eth2book.info/bellatrix/part2/consensus/casper_ffg) (Casper the Friendly Finality Gadget), the other [LMD GHOST](https://eth2book.info/bellatrix/part2/consensus/lmd_ghost) (Latest Message Driven Greedy Heaviest-Observed SubTree). The combination has become known as [Gasper](https://eth2book.info/bellatrix/part2/consensus/gasper). What do blocks in Gasper actually contain? 1. **Attestations** from other validators 2. The "**execution payload**" - i.e. an ordered list of all the transactions broadcast on the network 3. Opaque "**blobs**" of data (post EIP 4844) alongside the execution payload. These "blobs" assist rollups which need to post their proof or state change to Layer 1. This is discussed further in [[3. Data|Data]]. ## Fork Choices So, Proof of work and Proof of stake are sybil-resistant mechanisms which are often tightly coupled to the consensus protocol by this "fork choice rule"... What is a fork choice rule? There is a trade-off between a network always being able to work ("liveness") and it always and everywhere agreeing on one and only one state ("safety"). If you make your consensus protocol totally safe, that means when an unreliable node delivers a different state to its peers, the protocol stops. If you make the protocol always live, that means everyone may end up with different states and there will be no meaningful consensus. It's like the distributed systems equivalent of Heisenberg's Uncertainty Principle. Informally, an algorithm is said to be safe if "nothing bad ever happens" (safeness has to do with **consistency**). It is said to be live if "something good eventually happens" (liveness has to do with **availability**). For those familiar, the other aspect - partition tolerance - is resolved by the "[inactivity leak](https://eth2book.info/bellatrix/part2/incentives/inactivity)", though this also results in the ultimate safety failure: partitions eventually begin to finalise different histories and are forever independent of one another. The existence of forking in a consensus protocol is a consequence of prioritising liveness over safety: we want our network to continue working, even if there are slight differences in the order of transactions for short periods of time between different nodes. Rather than demanding that nodes always and everywhere agree on the state, we'd like them *to converge on the same state* over some predefined period of time. Given that the internet is an unreliable network, we end up with a "block tree" more than a "block chain", so the fork choice rule "is designed to select, from all the available branches, the one that is most likely to eventually end up in the final, linear, canonical chain." - Proof of work protocols use a "heaviest chain rule" (sometimes called "longest chain"). The head block is the tip of the chain that represents the most cumulative "work" done. - The fork choice rule in Casper FFG is "follow the chain containing the justified checkpoint of the greatest height", and to never revert a finalised block. - The fork choice rule in LMD GHOST involves counting accumulated votes from validators for blocks and their descendent blocks, in addition to the Casper FFG rule above. The basic idea in all these protocols is that we **assign a numeric score to a block**. The winning block, the head block, has the highest score. All correct nodes, when they see a certain block, will unambiguously agree that it is the head and choose to follow its branch whatever else is going on in their own views of the network. Thus, all correct nodes will eventually converge on a common view of a single canonical chain going back to genesis. Finality in Ethereum 2.0 is "economic finality", a detailed description of which you can find [here](https://blog.ethereum.org/2016/05/09/on-settlement-finality/). This is deeply related to what we say in [Kernel about censorhsip resistance and cost models](https://www.kernel.community/en/learn/module-6/censorship-resistance). Similarly, Ben finishes his post on consensus by writing: >Our ideal for the systems we are building is that they are _politically_ decentralised (for permissionlessness and censorship resistance), _architecturally_ decentralised (for resilience, with no single point of failure), but _logically_ centralised (so that they give consistent results). ### Clients 1. [Nimbus](https://nimbus.guide/) 2. [Lighthouse](https://lighthouse.sigmaprime.io/) 3. [Prysm](https://prysmaticlabs.com/) 4. [Lodestar](https://lodestar.chainsafe.io/) 5. [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) ### Resources If you'd like to go deeper, [here at the running notes of all consensus implementers' calls](https://hackmd.io/@benjaminion), by Ben Edgington. If you scroll down the list a little further, you'll see some "[What's New In Eth2](https://eth2.news)" posts, which have consistently been a favourite of mine. Ben wrote 100 editions - truly a work of great and enduring commitment. Author: cryptowanderer