Introduction

Ethereum, the ever-evolving blockchain powerhouse, has consistently delivered major upgrades that have opened new horizons in the world of blockchain and digital assets. As we’ve seen with previous milestones like EIP-1559 (London), EIP-3675 (Paris/The Merge), and EIP-4895 (Shanghai), these developments have historically spurred significant growth in the Ethereum ecosystem.

But what lies on the horizon? As we approach the end of this year, a highly anticipated update known as the Cancun upgrade beckons in the near term. Yet it’s not this update alone that has the crypto world abuzz. The standout star of Ethereum’s ongoing transformation is none other than EIP-4844, colloquially dubbed “Proto-Danksharding”. The protocol promises to inaugurate a substantial shift within Ethereum, aiming to make vital processes more cost-effective. To embark on this journey of Ethereum’s quest for enhanced scalability, let’s first dissect the exciting landscape that EIP-4844 brings.

What is Sharding?

In a traditional blockchain network, all nodes must process every transaction to ensure the legitimacy and smooth running of the network. However, this can become a bottleneck as the network grows in size and the number of transactions increases, often resulting in various adverse effects such as slower block confirmation and increased gas fees, both of which deter network participants’ activities.

In short, Sharding is a technique for dividing the blockchain into smaller partitions (shards). When a transaction is submitted, it is assigned to the shard that contains the data that is relevant to the transaction. The shard then processes the transaction and adds it to its own ledger, similar to how the main blockchain has its own ledger. The difference is that each shard’s ledger only contains a portion of the network’s total transactions.

As each shard operates independently, they can process unique transactions simultaneously. Consequently, this parallel processing mechanism boosts the network’s throughput proportionally to the number of operating shards which reduces the aforementioned bottlenecks.

Evolution of Ethereum:  From Full Execution to Data Sharding

The pursuit of network stability began long before Ethereum’s inception, as evidenced by the early proposals from the Ethereum community, including pioneering concepts like Hypercubes, Super Quadratic Sharding, and Hub-and-Spoke Chains. In fact, Vitalik Buterin, co-founder of Ethereum, personally introduced concepts of hypercube and hub-and-spoke chains in his early blog posts. These visionary methods laid the foundation for the quadratic sharding model, which has become an integral part of the “ETH2” roadmap. As Ethereum evolved, its sharding approach went through three significant transformations:

1. Transition to Quadratic Sharding (Late 2017): Amidst evolving research, the Ethereum community collectively decided to focus the R&D effort on implementing quadratic sharding over other scalability solutions. Briefly,  quadratic sharding aims to improve network scalability by separating a L1 into a Beacon chain and a number of Shard chains. Each Shard chain validates an independent set of transactions, which are then managed and finalized by the Beacon chain.
2. Redefined Beacon and Shard Chain Communication (2018): In April 2018, the proposal for crosslinks (an alternative solution that allowed dual-way communications between the Beacon chain and the Shard chains) was discarded to focus solely on unilateral communication of Shard Chains to the Beacon Chain for a simplified network design.
3. Introduction of the Rollup-Centric Roadmap (2020): In late 2020, Vitalik introduced the new Ethereum roadmap and the idea of leveraging rollups for transaction execution. Within this new plan, Shard Chains would function purely for data availability which emphasized Ethereum’s move from execution sharding to data sharding.

Ethereum’s sharding journey reflects an overarching goal: achieving scalability while simplifying the supposedly complex systems. The updated direction aimed for shards to operate strictly as a data availability layer for rollups. Within this paradigm, Dankrad Feist of the Ethereum Foundation proposed a method to allow a single block builder to create a beacon block comprising transactions from all shards. Concurrently, he introduced the Proposer Builder Separation (PBS) to minimize potential centralization in block creation. This approach was well-received and incorporated into Ethereum’s official roadmap, marking the advent of Danksharding.

What is Danksharding?

Unlike traditional sharding, which divides a network into multiple operational shards, Danksharding focuses on splitting the blockchain’s data itself (called data sampling) and assigns each piece to a different blob. Blobs are a new concept to danksharding which is essentially a chunk of data (larger than typically stored in a standard transaction) that is then processed by a single blob node, which is responsible for verifying the blob for validity and adding it to the blockchain.

Given the potential size and quantity of blobs, there comes a need for an efficient and secure storage solution. Without delving too deeply into the technical intricacies, Blob trees serve this purpose. They are essentially Merkle/hash trees used for verifying content within data blocks in the network. These trees also enable the verification of specific data without downloading the entire dataset, employing specific hashes to confirm data presence and its position cryptographically. In this design, each subsequent layer hashes pairs from the layer above, ultimately leading to a single root hash.

What is Proto-Danksharding?

As the name suggests, Proto-Danksharding, introduced as a part of EIP-4844, is a prototype of danksharding that provides the “scaffolding” or a framework to later implement other sharding upgrades. Due to the complexity of Danksharding, Proto-Danksharding acts as a simpler and more incremental upgrade which requires no changes to be made to the Ethereum consensus protocol.

Despite it being an intermediary step, Proto-Danksharding allows blobs to be stored on the consensus layer (previously the Beacon Chain) instead of the execution layer thus remaining inaccessible from Ethereum Virtual Machine (EVM), making blob data cheaper. In simplicity, the below comparison done by @Ebunker summarizes the aspects that blobs via EIP-4844 differ from traditional blocks:

Impacts on Layer-2 Solutions

While the primary purpose of EIP-4844 (Proto-Danksharding) is to reduce Ethereum gas fees by using blob-carrying transactions, its impact can be amplified to all Layer-2 (L2) roll-up solutions. 

First, let’s consider the impacts on L2 networks and their validators. Unlike Layer-1 (L1) validators for ETH mainnet that earn ETH rewards as incentives, L2 validators have a different and more complex profit dynamic. In short, apart from the hardware costs of running the nodes, L2 node operators are also susceptible to the costs of posting transactions on the ETH mainnet (gas fee). Therefore, L2 validators’ profits can be represented by the formula below:

Further research on Dune Analytics has shown that L2s, through this business model, can make millions in ETH profit every month. However, the specific profits to each validator are likely to be slightly lower as the calculation does not account for the hardware cost of running nodes.

Through EIP-4844, the data verification costs can be significantly reduced by sending transaction data to the blobspaces instead of the mainnet blockspaces, which in turn suggests a higher profit margin assuming that the transaction fees on L2s stay constant. However, L2s are likely to adjust their gas fee pricing mechanisms to incorporate these changes in their cost structures while retaining the ability to improve their profit margin.  

L2 users, therefore, would enjoy even lower gas fees. Specifically, research has shown that L2 transaction fees can be lowered by 10-100x, one of the key reasons stopping crypto’s mass adoption. 

Where Does The Future Lie With EIP-4844?

In conclusion, EIP-4844 stands as a crucial milestone on Ethereum’s roadmap, paving the way for the much-anticipated Cancun upgrade. As Ethereum continues its evolution, EIP-4844 promises to be a game-changer for the network’s scalability across both L1 and L2 solutions. This transformative upgrade holds the potential to elevate Ethereum to new heights in terms of adoption and utility.

History has shown that major Ethereum upgrades like EIP-1559, The Merge (EIP-3675), and The Shanghai Upgrade (EIP-4895) have triggered substantial changes in the ecosystem. For instance, EIP-1559 introduced the burning mechanism for ETH, which not only boosted network demand but also created a supply shock, leading to a remarkable 50% gain in ETH just one month after implementation.

Likewise, The Merge and The Shanghai Upgrade significantly fueled the adoption of liquid staking platforms such as Lido. The ability to unstake and withdraw staked ETH following the Shanghai upgrade resulted in a nearly 70% increase in total ETH deposits within just six months, making liquid staking derivatives a prominent narrative in the DeFi space and embraced by many top protocols in various forms.

EIP-4844 has the potential to usher in a similar wave of transformation across the Ethereum ecosystem, affecting both the L1 Mainnet and L2 roll-up solutions. As we approach this upgrade, it’s an exciting time to witness the changes and innovations it may bring to the Ethereum network. Ethereum’s journey for scalability and enhanced functionality continues, and EIP-4844 is a pivotal step forward in that direction.

FAQ

1. Q. How does EIP-4844 (proto-danksharding) compare to EIP-4488?
   A. EIP-4488 offers a simpler solution to manage data load by reducing gas costs and setting a block size limit. Proto-danksharding introduces a new transaction type with large fixed-size blobs, separating data storage between consensus and execution layers. While EIP-4488 minimizes immediate changes, proto-danksharding prepares for future full sharding with most changes upfront.
   
2. Q. What parts of full danksharding does proto-danksharding implement, and what remains to be implemented?
   A. The work that is already done in this EIP includes:

1. A new transaction type of the same format will need to exist in “full sharding”
2. All execution-layer logic required for full sharding
3. All execution/consensus cross-verification logic required for full sharding
4. Layer separation between BeaconBlock verification and data availability sampling blobs
5. Most of the BeaconBlock logic required for full sharding
6. A self-adjusting independent gas price for blobs

The work that remains to be done to get to full sharding includes:

1. A low-degree extension of the blob_kzgs in the consensus layer to allow 2D sampling
2. Actual implementation of data availability sampling
3. PBS (proposer/builder separation), to avoid requiring individual validators to process 32 MB of data in one slot
4. Proof of custody or similar in-protocol requirement for each validator to verify a particular part of the sharded data in each block

Disclaimer

This publication is provided for informational and entertainment purposes only. Nothing contained in this publication constitutes financial advice, trading advice, or any other advice, nor does it constitute an offer to buy or sell securities or any other assets or participate in any particular trading strategy. This publication does not take into account your personal investment objectives, financial situation, or needs. Treehouse does not warrant that the information provided in this publication is up-to-date or accurate.

---

Hyperion by Treehouse reimagines workflows for digital asset traders and investors looking for actionable market and portfolio data. Contact us if you are interested! Otherwise, check out Treehouse Academy, Insights, and Treehouse Daily for in-depth research.