Before EIP-4844, rollups had to store their data inside Ethereum blocks using calldata, which was expensive because the data stayed on-chain permanently. This method results in high costs for storing rollup transaction data, limiting the scalability of Ethereum and rollups alike. EIP-4844 introduced blobs — a new, cheaper, and temporary way to store rollup data. Instead of keeping data permanently on-chain, blobs allow rollups to post data more efficiently, reducing costs and helping Ethereum scale without compromising security.
In this blog, we will discuss in detail the issues that existed before EIP-4844 and how this update solves those problems. We will also address some important questions around blobs, rollups, and the future of Ethereum scaling.
Before EIP-4844: Understanding Rollups
For those who are already familiar with rollups, feel free to skip ahead. But for those who need a quick refresher, here’s the basic idea:
Rollups are Layer 2 scaling solutions for Ethereum. They process transactions off the main Ethereum chain (Layer 1), but still use Ethereum for security. By handling computations off-chain and bundling many transactions into a single one, rollups make Ethereum faster, cheaper, and more scalable. Arbitrum, Optimism, and similar chains are Layer 2 rollups built on top of Ethereum.
How Rollup Chains Operate Off-Chain
- Execution Off-Chain: These rollup chains (like Arbitrum) process the transactions off the Ethereum blockchain. When a user submits a transaction, it is first handled by the rollup chain (Arbitrum, Optimism, etc.), not Ethereum. This means they don’t have to wait for Ethereum’s block space and high gas costs.
- Bundling Transactions: Instead of sending each individual transaction to Ethereum, these rollups bundle multiple transactions into a single batch. They then submit this batch of transactions to Ethereum in one go. This reduces the total number of transactions Ethereum needs to handle, and each Ethereum transaction is much more efficient.
- State Changes Off-Chain: The changes (like balance updates) occur on the rollup chain itself. Ethereum doesn’t need to track every state change immediately. Only the final batch of transaction results or a proof (in zk-rollups) is sent to Ethereum to ensure everything is correct.
Main Purpose of Rollup Chains
- Reducing Congestion: Since most transactions happen off-chain, Ethereum doesn’t get overloaded with every single action. This makes Ethereum more efficient and reduces network congestion.
- Lowering Costs: Ethereum’s gas fees can be very high when the network is busy. Rollups like Arbitrum make transactions much cheaper because they handle computations off-chain and only post minimal data (like proofs or state roots) to Ethereum.
- Security and Decentralization: Rollups still rely on Ethereum to verify and settle final transaction data. This way, Ethereum’s security and decentralization benefits are preserved, but the rollups provide much higher throughput and lower costs.
Why Rollup Transactions Are Cheaper
- Minimal Ethereum Block Usage: In Ethereum, each transaction uses Ethereum’s block space, and the more data stored, the higher the gas fee. Rollups avoid storing each transaction on Ethereum and only post the essential data like proofs or compressed summaries. This drastically reduces the data size, meaning lower gas costs on Ethereum.
-
Off-Chain Execution: Rollups execute and store most of the transaction logic and state off-chain. The rollup chain handles the heavy computation and only submits the necessary information to Ethereum. Since Ethereum only verifies and finalizes the results, it avoids the high computational cost of processing every single transaction.
-
Data Compression: Rollups use data compression techniques, meaning they reduce the amount of data that needs to be posted to Ethereum. Instead of posting each transaction, they bundle multiple transactions and post only the compressed data (e.g., Merkle roots or cryptographic proofs). This compression leads to significantly lower costs than posting each transaction individually.
Why Do We Need EIP-4844?
Before EIP-4844, rollup chains like Optimism and Arbitrum would bundle many transactions together off-chain and generate a proof that summarized the result. This bundle of transactions, along with its proof, was then sent to Ethereum’s mempool just like any normal transaction. When Ethereum miners or validators picked up this transaction, they would verify the proof, meaning they would check if the bundle of off-chain transactions matches the submitted proof, but they would not re-run each individual transaction like they do for pure Ethereum transactions. Once verified, this bundled rollup transaction, along with its calldata (the data attached to interact with contracts), would be permanently stored in the Ethereum block, together with pure Ethereum transactions.
However, this method had a major downside. The calldata used to submit rollup bundles was expensive because storing any data permanently on Ethereum costs a lot of gas. Even though Ethereum wasn’t executing all the rollup transactions again, it still had to store their data forever. As rollup chains grew and sent more data to Ethereum, this increased the storage burden on Ethereum and made transactions costly for users. Essentially, rollup chains were supposed to help Ethereum scale and become cheaper, but the permanent storage of their data kept Ethereum expensive and made blockspace more congested.
What exactly does calldata do?
Calldata carries instructions and inputs that tell smart contracts what action to perform. It’s like sending a form with all the details needed to complete a task. Since Ethereum stores calldata permanently, it adds to network costs.
What EIP-4844 Brings to Ethereum
EIP-4844 is a major upgrade that is part of a bigger scaling roadmap called Proto-Danksharding. It is currently live but still seen as a temporary solution while full Danksharding is under research and development by the Ethereum community. The biggest change EIP-4844 brings is the introduction of a new type of transaction called a “blob-carrying transaction.” Instead of forcing rollup data to be stored permanently on Ethereum through calldata, blobs allow large amounts of data to be stored temporarily and much more cheaply. These blobs are attached to transactions but are not stored forever on Ethereum, reducing costs and freeing up blockspace, while still allowing rollups to prove their transactions securely.
What Are Blobs in EIP-4844?
Blobs are a new type of data introduced by EIP-4844 that helps scale Ethereum more efficiently. Unlike regular calldata, which stores data permanently on Ethereum, blobs allow temporary storage of large chunks of data. These blobs are attached to transactions in Ethereum blocks but are not stored forever. Instead, they only need to be stored long enough for rollup chains to prove their transactions.
How Does the Blob Transaction Process Work in EIP-4844?
When a rollup chain like Optimism or Arbitrum sends its bundled transactions to Ethereum, the data is not directly stored as calldata in the Ethereum blocks like before. Instead, the rollup chain sends a blob-carrying transaction to Ethereum. This transaction contains a proof and a blob, which is a temporary, compressed data storage. The proof ensures that the transactions in the blob are valid, and Ethereum validators only need to verify the proof instead of re-executing all the transactions, saving time and gas. Once the transaction with the blob is picked up from Ethereum’s mempool, the Ethereum validators check the proof to ensure the blob’s data matches the expected rules for rollup transactions.
The blob is then mapped to the Ethereum block where it is temporarily stored, but it is not permanently kept like traditional calldata. Instead, Ethereum stores a hash reference to the blob within the block. This reference allows Ethereum to link the temporary blob data to the block, which will be discarded after a certain period. The short-term storage of blobs helps Ethereum reduce the storage burden while still allowing rollups to use Ethereum for security.
For users who want to verify a rollup transaction, they can look at the Ethereum block where the blob-carrying transaction is included. By checking the proof and the hash reference to the blob, users can verify that the rollup transaction is valid without needing to access the entire data of the blob. The proof serves as a guarantee that the rollup data is correct and follows the right rules, while the reference in the Ethereum block guides users to verify the transaction efficiently.
What Happens to Temporary Storage? What If Someone Wants to Verify ?
The temporary storage of blobs in Ethereum is valid only for a short period, as they are not stored permanently in the blockchain. Once the expiration period for the blob has passed, the blob data is discarded and no longer available.
However, the validity of the transaction remains intact because Ethereum keeps a hash reference to the blob in the block. This reference allows anyone to verify the transaction’s validity, even after the blob data is removed, by checking the proof and the hash against the Ethereum block.
In short, users can still verify the transaction, but they rely on the proof and hash reference stored in the Ethereum block, rather than the actual blob data. The proof guarantees the correctness of the rollup transaction, while the reference ensures the integrity of the data.
How Do Validators Tell the Difference Between Regular Transactions and Blob Transactions?
When validators or proposers are building a block from the mempool, they differentiate transactions based on their transaction type. Each transaction has a specific structure:
- Ethereum Pure Transactions: These follow the standard Ethereum transaction format, such as sending ether, contract interactions, or token transfers. They don’t include blob data or proof.
- Blob Transactions: These are a new transaction type introduced by EIP-4844. Blob transactions contain proof and temporary blob data, which sets them apart from regular Ethereum transactions.
What are the different types of transactions in Ethereum and which EIPs introduced them?
- Type 0: Legacy Transactions
- Type 1: Access List Transactions (EIP-2930)
- Type 2: EIP-1559 Transactions
- Type 3: Blob Transactions (EIP-4844)
What is the size of a blob in EIP-4844, and how many blobs can be attached in a single Ethereum block?
- Blob Size: Each blob in EIP-4844 can be up to 1 MB in size.
- Number of Blobs per Block: Ethereum blocks can include a maximum of around 64 blobs, depending on the block’s overall size and gas limits.
How do blob transactions differ from traditional calldata?
Blob transactions in EIP-4844 are temporary data storage that is only referenced in Ethereum blocks, while traditional calldata is permanently stored in Ethereum blocks. Blob data is compressed and not fully stored on Ethereum, reducing gas costs, whereas calldata incurs high storage costs since it stays in the block forever.
How are pure Ethereum transactions and blob transactions stored in Ethereum blocks, and why are Ethereum transactions more expensive than blob transactions?
Pure Ethereum transactions are permanently stored in the block using calldata, which increases gas costs due to the long-term storage. In contrast, blob transactions are stored temporarily in the blob, with only a reference hash stored in the block. This reduces gas costs for blob transactions since the data isn’t stored permanently on Ethereum, making blob transactions cheaper compared to traditional Ethereum transactions.
What if I want to access blob data after its expiration?
Once the blob data expires, it is no longer stored on the Ethereum network, so it becomes inaccessible. You cannot retrieve the expired blob data from Ethereum. However, you can still verify the data (using the proof and reference hash) to ensure the blob’s validity within the temporary storage window. If you need to access the data after expiration, you would need to rely on the rollup chain that created the blob, as they may keep a copy off-chain. Ethereum itself will not store the expired blob data for future access.
Why are Ethereum pure transactions still using the traditional transaction method, given that blob transactions are cheaper?
Ethereum pure transactions still use the traditional method because they serve different purposes. These transactions are permanent and need to be securely stored on the Ethereum blockchain for applications that require immutable records. For many use cases, the cost of calldata and storage is justified because the transaction data needs to be immediately and permanently available. Additionally, traditional Ethereum transactions maintain compatibility with existing infrastructure and smart contracts. Blob transactions, on the other hand, are designed for rollups and Layer 2 solutions, offering more cost-effective temporary storage for large amounts of data that don’t need to be permanently stored on Ethereum. In short, pure Ethereum transactions are used when permanent, secure, and accessible data is needed, while blob transactions are for temporary, scalable solutions.
In conclusion, EIP-4844 introduces blob transactions to improve Ethereum’s scalability by offering a cost-effective way to temporarily store large amounts of data. While pure Ethereum transactions remain essential for permanent, secure, and accessible records, blob transactions help reduce costs and congestion, making Ethereum more efficient for rollups and Layer 2 solutions. This innovation strikes a balance between Ethereum’s core security and the need for scalability.