[
{
"title": "Blob throughput increase",
"url": "https://eips.ethereum.org/EIPS/eip-7691",
"date": "2025-05-07T00:00:00Z",
"description": "Pectra hardfork increases blob limits: target from 3 to 6 blobs and max from 6 to 9 blobs.",
"type": "general"
},
{
"title": "BPO1 blob throughput increase",
"url": "https://blog.ethereum.org/2025/11/06/fusaka-mainnet-announcement",
"date": "2025-12-09T00:00:00Z",
"description": "First Blob Parameter Only fork after Fusaka increases blob limits: target from 6 to 10 blobs and max from 9 to 15 blobs.",
"type": "general"
},
{
"title": "BPO2 blob throughput increase",
"url": "https://github.com/ethereum/pm/issues/1772",
"date": "2026-01-07T00:00:00Z",
"description": "Second Blob Parameter Only fork increases blob limits: target from 10 to 14 blobs and max from 15 to 21 blobs.",
"type": "general"
}
]
daLayer+7-1
{
"consensusAlgorithm": {
"name": "Gasper",
"description": "Ethereum's consensus protocol combines two separate consensus protocols, LMD GHOST and Casper FFG.\n LMD GHOST is a fork choice rule that essentially provides liveness to the chain. On the other hand, Casper FFG provides finality to the chain, protecting it from deep reversions.\n LMD GHOST provides the core of the chain fork choice rule, by selecting the Greedy Heaviest-Observed Sub-Tree (GHOST) and considering only the validators\n most recent vote (Latest Message Driven, LMD). Casper FFG is a finality gadget, it modifies the fork choice by making some of the chain branches inaccessible.\n Together they are known as \"Gasper\".",
"blockTime": 12,
"consensusFinality": 768,
"unbondingPeriod": 777600
},
"economicSecurity": {
"token": {
"symbol": "ETH",
"decimals": 18,
"coingeckoId": "ethereum"
}
},
"finality": 768,
"pruningWindow": 1555200,
"risks": {
"daLayer": {
"value": "Self-verify",
"sentiment": "good",
"description": "Full nodes download the full data for both transactions on the execution layer, and data blobs on the consensus layer. For a block to be considered valid, all data must be available and pass the is_data_available() check. From the rollup perspective, Ethereum's canonical chain cannot contain unavailable data commitments as full nodes self-verify the data availability of each block, discarding blocks with unavailable data.\n "
}
},
"systemCategory": "public",
"technology": {
"description": "\n## Consensus\nEthereum's consensus protocol combines two separate consensus protocols, LMD GHOST and Casper FFG.\nLMD GHOST is a fork choice rule that ensures the liveness of the chain by selecting the Greedy Heaviest-Observed Sub-Tree (GHOST), and considering only the validators most recent vote (Latest Message Driven, LMD). \nThe weight of a branch is calculated by summing the votes for its root block and those for all child branches, acknowledging that a vote for a block inherently supports all its ancestors. \n\n\n\n\nThis mechanism ensures that the branch with the greatest validator support is favored when making fork choices.\n\nOn the other hand, Casper FFG provides finality 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. \nThis finality mechanism prevents deep chain reorganizations.\n\nThe Ethereum consensus protocol is organized around two key time intervals: the slot and the epoch. \nA slot lasts 12 seconds, and an epoch comprises 32 slots, totaling 6.4 minutes. \n\nValidators provide attestations once per epoch. Attesters are divided into 32 committees, and each one of them votes on one slot during an epoch.\nEach attestation contains votes for the head of the chain, which LMD GHOST uses, and votes for checkpoints, which are utilized by Casper FFG. \nThe weight of a vote corresponds to the validator's effective balance which contributes to the overall weight of a branch in the chain.\nMoreover, 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. \n\n### Finality\nTo 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.\nCasper 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 network about other validators' views. \nIf 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.\n\n\n\n\nFinalization 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. \nA finalized checkpoint becomes irreversible unless at least 1/3 of the validators change their stance, which would lead to their stake being slashed. \n\nEquivocating (expressing two conflicting views) over blocks or attestations by a validator results in their stake being slashed.\n\n## Blobs (EIP-4844)\n[EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) introduces \"blob-carrying transactions,\" a new transaction type under [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) that allows for the inclusion of large data payloads, or blobs, within transactions.\nThese blobs are not directly accessible during EVM execution but can be verified through commitments.\nOn the consensus layer, blobs are referenced in the beacon block and propagated separately as \"sidecars,\" enabling forward compatibility with future data scaling methods like data-availability sampling (DAS).\nEIP-4844 also creates a new blob gas market, which operates similarly to [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)'s fee mechanism.\nThe blob base fee adjusts dynamically based on the number of blobs included in each block relative to the target.\nIf 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.\n\nThe initial blob parameters (target 3, max 6 blobs) were increased via [EIP-7691](https://eips.ethereum.org/EIPS/eip-7691) in the Pectra upgrade to target 6 and max 9 blobs.\nFollowing the Fusaka upgrade which enabled PeerDAS (Peer Data Availability Sampling), Blob Parameter Only (BPO) forks allow incremental blob capacity increases without hard forks.\nBPO1 raised the target to 10 and max to 15 blobs per block.\n\n## L2s Data Availability\n\nL2s 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.\nTo retrieve blobs, users have a limited window of 4096 epochs (~18 days) during which they can access them directly from the consensus client 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. \nFor transaction-specific blob retrieval, users must fetch all sidecar blobs from a block and identify the one corresponding to the desired versioned hash. \n\nOptimistic rollups use blob data primarily during the process of submitting fraud proofs. \nWhen a dispute arises, the rollup must provide the underlying data from a blob as part of the calldata. \nThe blob verification precompile is used to verify that the provided blob data corresponds to the versioned hash that was initially committed in the transaction. \nThis ensures that the data being used for fraud-proof verification is accurate and consistent with what was originally submitted. \n\nZK 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. \nThis method allows ZK rollups to prove that the data used in their validity proof is consistent with the blob data committed to Ethereum.\n ",
"description": "\n## Consensus\nEthereum's consensus protocol combines two separate consensus protocols, LMD GHOST and Casper FFG.\nLMD GHOST is a fork choice rule that ensures the liveness of the chain by selecting the Greedy Heaviest-Observed Sub-Tree (GHOST), and considering only the validators most recent vote (Latest Message Driven, LMD). \nThe weight of a branch is calculated by summing the votes for its root block and those for all child branches, acknowledging that a vote for a block inherently supports all its ancestors. \n\n\n\n\nThis mechanism ensures that the branch with the greatest validator support is favored when making fork choices.\n\nOn the other hand, Casper FFG provides finality 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. \nThis finality mechanism prevents deep chain reorganizations.\n\nThe Ethereum consensus protocol is organized around two key time intervals: the slot and the epoch. \nA slot lasts 12 seconds, and an epoch comprises 32 slots, totaling 6.4 minutes. \n\nValidators provide attestations once per epoch. Attesters are divided into 32 committees, and each one of them votes on one slot during an epoch.\nEach attestation contains votes for the head of the chain, which LMD GHOST uses, and votes for checkpoints, which are utilized by Casper FFG. \nThe weight of a vote corresponds to the validator's effective balance which contributes to the overall weight of a branch in the chain.\nMoreover, 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. \n\n### Finality\nTo 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.\nCasper 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 network about other validators' views. \nIf 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.\n\n\n\n\nFinalization 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. \nA finalized checkpoint becomes irreversible unless at least 1/3 of the validators change their stance, which would lead to their stake being slashed. \n\nEquivocating (expressing two conflicting views) over blocks or attestations by a validator results in their stake being slashed.\n\n## Blobs (EIP-4844)\n[EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) introduces \"blob-carrying transactions,\" a new transaction type under [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) that allows for the inclusion of large data payloads, or blobs, within transactions.\nThese blobs are not directly accessible during EVM execution but can be verified through commitments.\nOn the consensus layer, blobs are referenced in the beacon block and propagated separately as \"sidecars,\" enabling forward compatibility with future data scaling methods like data-availability sampling (DAS).\nEIP-4844 also creates a new blob gas market, which operates similarly to [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)'s fee mechanism.\nThe blob base fee adjusts dynamically based on the number of blobs included in each block relative to the target.\nIf 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.\n\nThe initial blob parameters (target 3, max 6 blobs) were increased via [EIP-7691](https://eips.ethereum.org/EIPS/eip-7691) in the Pectra upgrade to target 6 and max 9 blobs.\nFollowing the Fusaka upgrade which enabled PeerDAS (Peer Data Availability Sampling), Blob Parameter Only (BPO) forks allow incremental blob capacity increases without hard forks.\nBPO1 raised the target to 10 and max to 15 blobs per block.\nBPO2 raised the target to 14 and max to 21 blobs per block.\n\n## L2s Data Availability\n\nL2s 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.\nTo retrieve blobs, users have a limited window of 4096 epochs (~18 days) during which they can access them directly from the consensus client 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. \nFor transaction-specific blob retrieval, users must fetch all sidecar blobs from a block and identify the one corresponding to the desired versioned hash. \n\nOptimistic rollups use blob data primarily during the process of submitting fraud proofs. \nWhen a dispute arises, the rollup must provide the underlying data from a blob as part of the calldata. \nThe blob verification precompile is used to verify that the provided blob data corresponds to the versioned hash that was initially committed in the transaction. \nThis ensures that the data being used for fraud-proof verification is accurate and consistent with what was originally submitted. \n\nZK 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. \nThis method allows ZK rollups to prove that the data used in their validity proof is consistent with the blob data committed to Ethereum.\n ",
"references": [
{
"title": "EIP-4844",
"url": "https://eips.ethereum.org/EIPS/eip-4844"
},
{
"title": "Ethereum Technical Handbook",
"url": "https://eth2book.info/latest/"
}
]
},
"throughput": [
{
"size": 786432,
"target": 393216,
"frequency": 12,
"sinceTimestamp": 1710288000
},
{
"size": 1179648,
"target": 786432,
"frequency": 12,
"sinceTimestamp": 1746612300
},
{
"size": 1966080,
"target": 1310720,
"frequency": 12,
"sinceTimestamp": 1765290071
},
{
"size": 2752512,
"target": 1835008,
"frequency": 12,
"sinceTimestamp": 1767747671
}
],
"type": "Public Blockchain",
"usedWithoutBridgeIn": [],
"validators": {
"type": "dynamic"
}
}