The Bottlenecks of the Ethereum Architecture
The known architecture of Ethereum faces substantial bottlenecks, primarily centered around scalability and transaction throughput. One of the critical challenges lies in Ethereum's reliance on a single chain structure, where every node in the network must process every transaction. This architecture, while ensuring security and decentralization, imposes significant limitations on scalability. The current Ethereum base layer can only handle about 15-30 transactions per second (TPS), a stark contrast to the needs of a global-scale financial infrastructure.
The shift from Proof-of-Work to Proof-of-Stake (PoS) consensus mechanisms marked a significant milestone for Ethereum and its Layer 2 (L2). Transactions on Layer 2 (L2) blockchains like Optimism and Arbitrum are already cheaper than those on the Ethereum mainnet. These L2 solutions achieve lower costs by processing transactions off-chain and then periodically sending batches of transaction data back to Ethereum for verification and security. However, this data is stored on Ethereum indefinitely, even when it is no longer needed, which contributes to the growing size of the Ethereum blockchain and increases storage costs.
However, there is a pressing demand for further improvements that allow transactions to be settled more cheaply and alleviate the burden of the network’s block sizes. Hence, the need for the EIP-4844. EIP-4844 approach specifically focuses on enhancing the data layer of Ethereum, which interacts with the execution client (Ethereum Virtual Machine, or EVM) and other L2.
What Is Proto-Danksharding?
The term sharding Sharding refers to dividing the network into smaller units called “shards” that can process transactions in parallel. That is, transactions will be validated on individual shards rather than across the entire network. This approach is, however, poses challenges, such as security compromise due to small validators per shard and the complexities involved in migrating data between shards.
Ethereum’s Proto-Danksharding is an interim form of full sharding that implements a new transaction type that holds an additional data field called a blob (B-inary L-arge OB-ject.). Traditionally, rollups compress batches of transactions and post them to the L1. This process relies on storing all the data in calldata, which is then verifiable because it resides on-chain. Unlike rollup calldata that permanently reside on the blockchain, Blob-carrying transactions self-destruct after a period of 20 days on the consensus layer (aka Beacon nodes) to relieve data bloat.
These blobs are about 128 kB consisting of 4096 field elements, each 32 bytes in size. They are committed using the KZG (Kate-Zaverucha-Goldberg), a fixed-size vector commitment scheme that enables data availability sampling. This process allows nodes to verify that data is available and correct without needing to download the entire dataset, thus improving scalability and efficiency.
Rollups: Utilizing Blobs for Validation
The core challenge with blobs is that the data contained within them cannot be directly accessed by the Ethereum Virtual Machine (EVM). Instead, what is stored on-chain is a cryptographic hash of the blob's contents, referred to as the BLOBHASH. This hash acts as a commitment to the data stored in the blob, serving as proof that the data exists without revealing its content.
For zk-rollups, which use zero-knowledge proofs, the prover generates a proof that demonstrates knowledge of the input data without revealing it. This proof is then verified against the BLOBHASH stored on-chain, confirming that the data conforms to the expected structure and values without exposing the data itself 2.
For optimistic rollups, the process involves submitting a batch of transactions along with a root hash. Validators then check this root hash against the BLOBHASH of the corresponding blob. If the hashes match, it confirms that the transactions were correctly computed and stored in the blob, thus validating the rollup transaction.
Multi-Dimensional Fee Market by EIP-4844.
The existing fee market, established by EIP-1559, is primarily designed for processing blocks and is insufficient for managing blob-related costs. To bridge this gap, EIP-4844 proposes a multi-dimensional fee market that distinguishes between fees for regular transaction data and fees for blob data.
-The regular transaction data (like smart contract interactions, token transfers, etc.),
-The blob data introduced in EIP-4844.
This dual fee structure ensures that the network can efficiently allocate resources and maintain operational efficiency, even as it handles larger volumes of data.
Top comments (0)