A technical analysis

Introduction

EIP-4844, also known as “Shard Blob Transactions” or proto-danksharding, has arguably become the most anticipated post-Merge upgrade to Ethereum. The proposal is designed to accomplish two main objectives: (1) significantly reduce L2 rollup gas costs, and (2) serve as a stepping stone towards the full danksharding design introduced by EF researcher Dankrad Feist in December 2021.

This paper provides a technical overview of the proto-danksharding proposal, calls attention to three main technical risks for Ethereum, and discusses potential implications across the broader web3 industry. But first, some context.

Rollup-centric roadmap

In October 2020, following the announcement of the Optimism testnet, Vitalik published A roll-up centric ethereum roadmap in the Ethereum Magicians forum. In the post, Vitalik acknowledges the fact that rollups were proving to be a more practical and imminent scaling solution than those offered by the original eth2 roadmap.

In light of this, Vitalik proposed that the roadmap be rearranged to optimize for the needs of rollups. The bulk of rollups’ current L1 gas costs come from regularly posting their L2 block data to Ethereum, which they rely on for data availability. Thus Vitalik suggested refocusing base-layer scaling efforts to make data cheaper, rather than computation.

Design criteria

Making data cheaper is not as easy as simply repricing transaction calldata –– we must also consider the properties of Ethereum that we’d like to preserve. The design criteria for a compelling rollup-centric upgrade to Ethereum can be distilled down to the following:

  1. Reduce L1 data costs for rollups
  2. ... while retaining security against DoS
  3. ... and containing disk space growth from historical data.

Before we evaluate proto-danksharding in terms of the above criteria, we will look at an earlier, simpler proposal that has also gained some traction: EIP-4488.

EIP-4488

EIP-4488 accomplishes the above with the following three provisions:

  1. Reduce calldata cost to 3 gas per byte (currently 4 gas per zero byte and 16 gas per nonzero byte).
  2. Capping the total calldata per block to 1 MB plus 300 bytes per transaction, for a worst-case block size of ~1.4 MB. This compensates for the decreased cost per byte, which would otherwise increase worst-case network load to DoS levels.
  3. EIP-4444 is presented as a companion proposal that would be implemented with or soon after EIP-4488. EIP-4444 would allow clients to delete historical data older than one year. This compensates for the increased disk space growth that would come with decreased calldata costs.