In order to onboard the next billion users to Ethereum, we need to meet them where they already are. To achieve this, scalability is of paramount importance. Currently, Ethereum is limited to 15 transactions per second (~55 if we consider L2 transactions), which makes it difficult to keep up with competitors such as the Lightning Network (30 million tps) or Visa (which can handle up to 24,000 tps). Thanks to Ethereum's rollup-centric roadmap, we are now preparing for the next upgrade, Cancun-Deneb (Dencun). That will introduce Proto-danksharding (EIP-4844) as well as a series of improvements, which will bring changes to both the execution layer and the consensus layer.
What is Danksharding?
Danksharding is a sharding design that splits Ethereum blocks into shards. As more block space is introduced, blocks become larger in size (see next section), creating a need to reduce the workload on nodes and help Ethereum scale. In this design, a single validator is responsible for fragmenting the blocks and dispersing them to all the data shards.
What is Proto-danksharding?
Proto-danksharding is the first protocol upgrade before full sharding is achieved. It aims to create a new Ethereum landscape where more block space is available for L2 scaling solutions (multiple EVMs, OVMs, ZkEVMs running in parallel) to process more transactions off-chain in a cost-effective manner. As a result, it aims to offer a temporary scaling relief for rollups, making Layer 2 transactions as cheap as possible for users.
Source: Protolambda at Devconnect Amsterdam 2022
What does Proto-Danksharding really introduce?
- New transaction type: called a "blob-carrying transaction." This type will allow for extra space for data on transactions. Proto-Danksharding will limit the number of blobs in each block to 16, with each no larger than 128 KB, adding roughly 2 MB of space to the blocks. During Danksharding, however, more blobs will be allowed, increasing the number of data blobs in a single block to 256.
- Consensus layer storage: all blobs will be stored in a sidecar on the consensus layer.
- 2-Dimension fee market: proto-Danksharding will introduce a new fee mechanism for blob-data (data fees). The two-dimensional nature means that block builders will need to simultaneously avoid hitting two different limits (gas limit and data limit), when accepting transactions.
- KZG commitments: A KZG commitment is a cryptographic commitment scheme that allows a committer to bind themselves to the blob data without revealing it. This helps with both integrity and privacy of blob data off-chain, since blob data is not accessible to EVM execution, the EVM can only view a KZG commitment to the blob.
- No sharding: there will be no sharding during Proto-Danksharding since it's only one incremental step toward full sharding.
L2s: big winners?
Roll-ups are a combination of off-chain data, which includes all transactions that occurred off-chain, and execution checks that represent the state before and after. Both optimistic and zk rollups will leverage the extra data space to post commitments to transaction data on-chain and make the actual data available in data blobs instead of calldata (a read-only memory) which will make it even cheaper to store. This upgrade will reduce how expensive user transactions are on L2s since more than 90% of their clients' fees are spent on paying Ethereum data fees (source: https://dune.com/optimismfnd/optimism-l1-batch-submission-fees-security-costs).
Long live the Block Builders!
In a post EIP-4844 world, users will submit their blob-carrying transactions to block builders. A block builder creates their best block by selecting a number of client data blobs, as well as a combination of public and private transactions. They then submit their proposed blocks to the current block proposer. The block proposer selects one of the blocks and posts it to the network.
Toward full sharding, proposers will be accountable for all data shards, which means builders must disperse block data fragments to those shards and compute the KZG witnesses for the samples. Therefore, builders will require more networking and computing resources. That is why PBS was an essential milestone in the roadmap to help alleviate the burden on proposers.
Are you curious about how to run your own builder and more on what’s upcoming to achieve full sharding? Reach out to us!
