Ethereum

ConsensusAn agreement on the latest and correct state of a blockchain. Unlike L1 blockchains which coordinate participating nodes with consensus rules, rollups rely on L1s for reaching consensus by checking the state of the rollup smart contract deployed thereon.

Ethereum’s consensus protocol combines two separate consensus protocols, LMD GHOST and Casper FFG. LMD GHOST is a fork choice rule that ensures the livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. of the chain by selecting the Greedy Heaviest-Observed Sub-Tree (GHOST), and considering only the validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier most recent vote (Latest Message Driven, LMD). The weight of a branch is calculated by summing the votes for its root blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. and those for all child branches, acknowledging that a vote for a block inherently supports all its ancestors.

This mechanism ensures that the branch with the greatest validator support is favored when making fork choices.

On the other hand, Casper FFG provides finalityStrongest confirmation rule that can be given on the ordering of transactions. On Ethereum, a transaction is finalized when the corresponding epoch becomes final, which currently takes around 15 mins from transaction inclusion. A rollup transaction can be said to be final when the corresponding data is published to L1 and its ordering cannot be reverted. If outputs, i.e. state diffs are published, then also a proof proving their correctness must be verified to consider the transaction final. to the chain by modifying the fork choice rule. It ensures that once certain blocks are finalized, they are protected from being reverted, effectively pruning branches from the block tree. This finality mechanism prevents deep chain reorganizations.

The Ethereum consensus protocol is organized around two key time intervals: the slot and the epoch. A slot lasts 12 seconds, and an epoch comprises 32 slots, totaling 6.4 minutes.

Validators provide attestations once per epoch. Attesters are divided into 32 committees, and each one of them votes on one slot during an epoch. Each attestation contains votes for the head of the chain, which LMD GHOST uses, and votes for checkpoints, which are utilized by Casper FFG. The weight of a vote corresponds to the validator’s effective balance which contributes to the overall weight of a branch in the chain. Moreover, in each slot one validator is chosen to propose a block which includes updates to the beacon state, attestations, and the execution payload containing Ethereum user transactions.

Finality

To ensure consistency among validators voting at different times within an epoch, they are required to vote for a common checkpoint, specifically the first slot of the epoch. Casper FFG achieves finality through a two-round process. In the first round, each validator proposes what they believe is the best checkpoint and collects attestation from the networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. about other validators’ views. If 2/3 of the validators agree on the same checkpoint, it becomes justified. In the second round, validators share the justified checkpoint from the first round. If again 2/3 of the validators agree, the checkpoint is finalized.

Finalization is achieved when confirmation is received from over 2/3 of the validators, indicating that they have observed commitments from more than 2/3 of the validators agreeing not to revert the checkpoint. A finalized checkpoint becomes irreversible unless at least 1/3 of the validators change their stance, which would lead to their stake being slashed.

Equivocating (expressing two conflicting views) over blocks or attestations by a validator results in their stake being slashed.

BlobsThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally. (EIP-4844)

EIP-4844 introduces “blob-carrying transactions,” a new transaction type under EIP-2718 that allows for the inclusion of large data payloads, or blobs, within transactions. These blobs are not directly accessible during EVM execution but can be verified through commitments. On the consensus layer, blobs are referenced in the beacon block and propagated separately as “sidecars,” enabling forward compatibilityThe degree to which a rollup can make use of existing patterns, code, and tooling from another blockchain or development environment. Today, this typically refers to how well rollups and developers thereon can make use of the Ethereum Virtual Machine, existing smart contracts, and other Ethereum infrastructure. with future data scaling methods like data-availability sampling (DAS). EIP-4844 also creates a new blob gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. market, which operates similarly to EIP-1559’s fee mechanism. The blob base fee adjusts dynamically based on the number of blobs included in each block relative to the target. If a block contains more blobs than the target, the blob base fee increases, discouraging additional blob usage in subsequent blocks. Conversely, if a block contains fewer blobs than the target, the blob base fee decreases, encouraging more blob usage. If the number of blobs in a block matches the target, the blob base fee remains unchanged.

The initial blob parameters (target 3, max 6 blobs) were increased via EIP-7691 in the Pectra upgrade to target 6 and max 9 blobs. Following the Fusaka upgrade which enabled PeerDAS (Peer Data AvailabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. Sampling), Blob Parameter Only (BPO) forks allow incremental blob capacity increases without hard forks. BPO1 raised the target to 10 and max to 15 blobs per block. BPO2 raised the target to 14 and max to 21 blobs per block.

L2s Data Availability

L2s can post data a Ethereum by submitting a type-3 transaction, which includes the standard transaction fields along with commitments (versioned hashes) to one or more blobs. Any unused space within a blob still incurs full costs, as gas is charged per blob. To retrieve blobs, users have a limited window of 4096 epochs (~18 days) during which they can access them directly from the consensus clientSometimes labelled interchangeably as a “node”, they are tasked with processing transactions and managing the blockchains's state. They run the computations for each transaction according to the rollup's virtual machine and protocol rules. If comparing to Ethereum clients, these would be execution clients such as Geth, as opposed to consensus clients. using the getBlobSidecars() API call. This API retrieves blobs associated with a specific block rather than a specific transaction. If blobs older than the pruning window need to be accessed, they can be retrieved from an indexer or archiver via API. For transaction-specific blob retrieval, users must fetch all sidecar blobs from a block and identify the one corresponding to the desired versioned hashA fixed-length fingerprint of variable-size input, produced by a hash function..

Optimistic rollups use blob data primarily during the process of submitting fraud proofs. When a dispute arises, the rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. must provide the underlying data from a blob as part of the calldata. The blob verification precompile is used to verify that the provided blob data corresponds to the versioned hash that was initially committed in the transaction. This ensures that the data being used for fraud-proof verification is accurate and consistent with what was originally submitted.

ZK rollups, on the other hand, use the point evaluation precompile to verify that specific points in the polynomial (represented by the blob) match the expected values. This method allows ZK rollups to prove that the data used in their validity proofThe output of a cryptographic proving system attesting to correct computation. ZK-Rollups use succinct validity proofs (also called zero-knowledge proofs) to prove a batch of rollup transactions and blocks were properly executed. Validity proofs are submitted to a verifier, such as an Ethereum smart contract, which accepts them if properly constructed. is consistent with the blob data committed to Ethereum.

Enshrined BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge.

The DA bridgeSystem that verifies that data has been made available. It takes the form of a smart contract verifying a consensus or, if the data is verified directly by either downloading the full data or sampling, of an enshrined bridge. on Ethereum is enshrined, meaning that blob data is directly accessible on the consensus layer, with data availability guaranteed by the network’s inherent consensus rules. If a block contains unavailable data, full nodes will reject it, causing the chain to fork away from that block. This ensures data availability without requiring additional trust assumptions. In contrast, external DA providers must rely on data availability attestations from the external validator set, introducing an extra layer of trust on the majority of validators.