EIP-4844: The setup for a rollup-centric Ethereum

Share Dialog

The name, “proto-dank sharding”, is a play-on-words that derives from the names of two authors of the EIP (Ethereum Improvement Proposal), Dankrad Feist (https://github.com/dankrad) and Proto Lambda (https://github.com/protolambda).  

EIP-4844  can also be considered an early realization of the Modular Blockchain Architecture – where key blockchain component functions like State, Execution, and Data Availability are seperated at the client level.

The explicit goal of the proposed upgrade is to enable a rollup-centric ethereum, today, in a way that enables forward-compatibility for future sharding upgrades at the consensus layer.  The EIP-8448 upgrade accomplishes this in a way that minimizes disk usage, and prevents the baggage of permanent state bloat through pre-defined pruning intervals (blobs are pruned on a 1 month basis).

Critical to the EIP-4844 proposal, is the Introduction of a new transaction format for ethereum, called a blob.  A blob is contained within the ethereum beacon client (ie - Prysm), but not the execution environment itself (ie – GETH).

Previous attempts at rollup-centric danksharding (namely, EIP-4488) aimed to simply reduce the gas-cost of calldata, thus enabling inclusion of rollup data onchain via calldata mechanism.  

Proto-danksharding instead proposes  a separate transaction type (called a “blob” or “blob-carrying transaction”) that can hold cheaper data in large fixed-size blobs, with a limit on how many blobs can be included per block. 

A blob is basically a small amount of enclaved data that is held and made available by the ETH validating client at the consensus layer (beacon chain) rather than the execution layer (EVM).

In the EIP-4844 proposal, blobs are limited to 1 MB in size and raise the maximum block size on ethereum to about 2 MBs.  Notably, this works out to about 2.5 TB per year, a far higher growth rate than Ethereum requires today.

In an attempt to prevent the inherent state bloat that would be required for ethereum validators supporting the inclusion of a “blob” data type (a blockchain storage increase of about 2.5 TBs annually), EIP-4844 has suggested the following:

“In the case of proto-danksharding, the consensus layer can implement separate logic to auto-delete the blob data after some time (eg. 30 days), regardless of whether or not EIP-4444 is implemented. However, implementing EIP-4444 as soon as possible is highly recommended regardless of what short-term data scaling solution is adopted.”

•  Vitalik Buterin, https://www.eip4844.com/#reasons

EIP-4444 is a mechanism for pruning state in the ethereum blockchain.  This EIP applies specifically to clients, and enables them the option to locally prune headers, block bodies, and receipts that is older than HISTORY_PRUNE_EPOCHS epochs.  

This proposal makes the assumption that clients external to the ethereum validator will preserve the historic state on networks like IPFS, the proposed Portal Network, or The Graph.

Largely this concept of state pruning is fundamentally unique to the ethereum network, as it further splits the concept of an “Archival Node” with a “Validating Node” – which, on traditional blockchain networks like Bitcoin, are closely coupled (aka – all bitcoin nodes must have complete state history).

In the long run, Vitalik and the Ethereum foundation believes that adopting some history expiry mechanism is essentially mandatory – as full sharding would add about 40 TB of historical blob data per year, so users could only realistically store a small portion of it for some time.

In a sharded consensus paradigm, each shard would have its own dynamic fee model for gas and state reconciliation/propagation – adding complexity to an already complex system.

Rather than forcing the emergence of separate fee markets on ethereum, EIP-4844 enables a “merged fee market” due to the shared consensus layer.  This is important as it avoids the complexity of having to solve distinct fee markets for sharding.

Instead of there being a fixed number of shards that each have distinct blocks and distinct block proposers, in Danksharding there is only one proposer that chooses all transactions and all data that go into that slot.

This means that ethereum retains a single, unified state history and consensus layer, with the optionality for forwards-compatibility for a post-sharding architecture built in.

Forward compatibility is a concept which can broadly be defined as “a design characteristic that allows a system to accept input intended for a later version of itself.”  

An example of both design ideas can be found in web browsers. At any point in time, a current browser is forward compatible if it gracefully accepts a newer version of HTML

EIP-4844 is forward compatible as it is designed for a post-sharding implementation of Ethereum.  It implements a new transaction type, of the exact same format that will need to exist in “full sharding”.  This includes all of the execution-layer logic required for full sharding, as well as the execution / consensus cross-verification logic.

EIP-4844 also has a separation between block verification and the data availability for sampling blocks (based on a method called erasure-coding).  

Finally, EIP-4844 includes a self-adjusting independent gasprice for blobs, separating it from the core blockdata used in consensus, and facilitating the onboarding for rollups.

At Decentral Park, we are closely monitoring the proposed updates to Ethereum, keeping a close eye on how protocol changes affect the Ethereum fee market, user experience, and enable new types of applications with higher-throughput without security trade-offs.

To stay in the loop around our thematic research – which includes data on fundamental price indicators, regulatory movements, and more – check out https://decentralparkcapital.substack.com/s/thematic-research

You can sign up for our weekly newsletter here: https://decentralparkcapital.substack.com/s/the-weekly

The name, “proto-dank sharding”, is a play-on-words that derives from the names of two authors of the EIP (Ethereum Improvement Proposal), Dankrad Feist (https://github.com/dankrad) and Proto Lambda (https://github.com/protolambda).  

EIP-4844  can also be considered an early realization of the Modular Blockchain Architecture – where key blockchain component functions like State, Execution, and Data Availability are seperated at the client level.

The explicit goal of the proposed upgrade is to enable a rollup-centric ethereum, today, in a way that enables forward-compatibility for future sharding upgrades at the consensus layer.  The EIP-8448 upgrade accomplishes this in a way that minimizes disk usage, and prevents the baggage of permanent state bloat through pre-defined pruning intervals (blobs are pruned on a 1 month basis).

Critical to the EIP-4844 proposal, is the Introduction of a new transaction format for ethereum, called a blob.  A blob is contained within the ethereum beacon client (ie - Prysm), but not the execution environment itself (ie – GETH).

Previous attempts at rollup-centric danksharding (namely, EIP-4488) aimed to simply reduce the gas-cost of calldata, thus enabling inclusion of rollup data onchain via calldata mechanism.  

Proto-danksharding instead proposes  a separate transaction type (called a “blob” or “blob-carrying transaction”) that can hold cheaper data in large fixed-size blobs, with a limit on how many blobs can be included per block. 

A blob is basically a small amount of enclaved data that is held and made available by the ETH validating client at the consensus layer (beacon chain) rather than the execution layer (EVM).

In the EIP-4844 proposal, blobs are limited to 1 MB in size and raise the maximum block size on ethereum to about 2 MBs.  Notably, this works out to about 2.5 TB per year, a far higher growth rate than Ethereum requires today.

In an attempt to prevent the inherent state bloat that would be required for ethereum validators supporting the inclusion of a “blob” data type (a blockchain storage increase of about 2.5 TBs annually), EIP-4844 has suggested the following:

“In the case of proto-danksharding, the consensus layer can implement separate logic to auto-delete the blob data after some time (eg. 30 days), regardless of whether or not EIP-4444 is implemented. However, implementing EIP-4444 as soon as possible is highly recommended regardless of what short-term data scaling solution is adopted.”

•  Vitalik Buterin, https://www.eip4844.com/#reasons

EIP-4444 is a mechanism for pruning state in the ethereum blockchain.  This EIP applies specifically to clients, and enables them the option to locally prune headers, block bodies, and receipts that is older than HISTORY_PRUNE_EPOCHS epochs.  

This proposal makes the assumption that clients external to the ethereum validator will preserve the historic state on networks like IPFS, the proposed Portal Network, or The Graph.

Largely this concept of state pruning is fundamentally unique to the ethereum network, as it further splits the concept of an “Archival Node” with a “Validating Node” – which, on traditional blockchain networks like Bitcoin, are closely coupled (aka – all bitcoin nodes must have complete state history).

In the long run, Vitalik and the Ethereum foundation believes that adopting some history expiry mechanism is essentially mandatory – as full sharding would add about 40 TB of historical blob data per year, so users could only realistically store a small portion of it for some time.

In a sharded consensus paradigm, each shard would have its own dynamic fee model for gas and state reconciliation/propagation – adding complexity to an already complex system.

Rather than forcing the emergence of separate fee markets on ethereum, EIP-4844 enables a “merged fee market” due to the shared consensus layer.  This is important as it avoids the complexity of having to solve distinct fee markets for sharding.

Instead of there being a fixed number of shards that each have distinct blocks and distinct block proposers, in Danksharding there is only one proposer that chooses all transactions and all data that go into that slot.

This means that ethereum retains a single, unified state history and consensus layer, with the optionality for forwards-compatibility for a post-sharding architecture built in.

Forward compatibility is a concept which can broadly be defined as “a design characteristic that allows a system to accept input intended for a later version of itself.”  

An example of both design ideas can be found in web browsers. At any point in time, a current browser is forward compatible if it gracefully accepts a newer version of HTML

EIP-4844 is forward compatible as it is designed for a post-sharding implementation of Ethereum.  It implements a new transaction type, of the exact same format that will need to exist in “full sharding”.  This includes all of the execution-layer logic required for full sharding, as well as the execution / consensus cross-verification logic.

EIP-4844 also has a separation between block verification and the data availability for sampling blocks (based on a method called erasure-coding).  

Finally, EIP-4844 includes a self-adjusting independent gasprice for blobs, separating it from the core blockdata used in consensus, and facilitating the onboarding for rollups.

At Decentral Park, we are closely monitoring the proposed updates to Ethereum, keeping a close eye on how protocol changes affect the Ethereum fee market, user experience, and enable new types of applications with higher-throughput without security trade-offs.

To stay in the loop around our thematic research – which includes data on fundamental price indicators, regulatory movements, and more – check out https://decentralparkcapital.substack.com/s/thematic-research

You can sign up for our weekly newsletter here: https://decentralparkcapital.substack.com/s/the-weekly

<100 subscribers

<100 subscribers