## EIP-4844: Revolutionizing Layer 2 Scaling with Blob Transactions The Dencun network upgrade, activated on March 13, 2024, marked a significant milestone in Ethereum's scalability roadmap by introducing EIP-4844, also known as Proto-Danksharding. This pivotal upgrade brought forth a new transaction type: Blob Transactions (Type 3). The primary objective of these transactions is to drastically lower the costs for Layer 2 (L2) rollups to post their data to the Ethereum Layer 1 (L1) mainnet, ultimately making transactions on L2 solutions significantly cheaper for end-users. ## Understanding Blob Transactions: The Core Innovation To appreciate the impact of EIP-4844, it's essential to distinguish between traditional Ethereum transactions and the new blob-carrying transactions: * **Normal Transactions (Type 2 - EIP-1559):** In standard Ethereum transactions, all associated data, including input data (known as `calldata`), is permanently stored on the Ethereum blockchain. Every Ethereum node is required to store this data indefinitely. * **Blob Transactions (Type 3 - EIP-4844):** These transactions introduce a novel component: "blobs." Blobs are large, additional chunks of data carried by the transaction. Crucially, this blob data is *not* stored permanently by the L1 execution layer (the Ethereum Virtual Machine - EVM). Instead, it's guaranteed to be available on the consensus layer for a temporary period—approximately 18 days (or 4096 epochs)—after which it is pruned (deleted) by the nodes. The core transaction details (such as sender, recipient, value, etc.) remain permanently stored on-chain. Think of a blob as a temporary "sidecar" attached to a motorcycle (the transaction). The motorcycle and its essential components are kept, but the sidecar, after serving its purpose of temporary data transport, is eventually detached and discarded. **What are Blobs?** The term "blob" is a common shorthand for Binary Large Object. In the context of EIP-4844: * Blobs are substantial, fixed-size data packets, each precisely 128 Kilobytes (KiB). This size is composed of 4096 individual fields, each 32 bytes long. * They provide a dedicated and more economical data space for L2 rollups to post their transaction batches, compared to the previously used, more expensive `calldata`. ## The Problem Solved: Why Blob Transactions Were Needed Ethereum's L1 has historically faced high transaction fees due to its limited block space and substantial demand. This is a direct consequence of the blockchain trilemma, which posits a trade-off between scalability, security, and decentralization. Layer 2 rollups (such as ZK Sync, Arbitrum, and Optimism) have emerged as the primary scaling solution for Ethereum. They work by: 1. Executing transactions off-chain (on the L2). 2. Batching many transactions together. 3. Compressing this batch. 4. Posting the compressed batch data back to the L1 mainnet for security and data availability. **The Pre-Blob Bottleneck:** Before EIP-4844, rollups posted their compressed transaction batches to L1 using the `calldata` field of a standard L1 transaction. This approach was a significant cost driver because: * `Calldata` consumes valuable and limited L1 block space. * This `calldata` had to be stored *permanently* by all L1 nodes. This was inefficient because the L1 primarily needed to verify the *availability* of this data temporarily, not store it forever. * The requirement for permanent storage of large data volumes increases hardware and computational demands on node operators, which directly translates into higher gas fees for all users. Imagine being forced to carry around every exam paper you ever passed, indefinitely; this is analogous to the burden of permanent calldata storage for data that only needed short-term verifiability. Consequently, rollups were incurring substantial fees for this permanent calldata storage, a feature they didn't strictly require for their long-term operational integrity. ## How EIP-4844 Works: The Mechanics of Blobs EIP-4844, or Proto-Danksharding, provides an elegant solution by allowing rollups to post their data as blobs instead of relying solely on `calldata`. * **Temporary Data Availability:** Blobs are designed for short-term data availability. After the defined window (around 18 days), this data is pruned from the consensus layer. This significantly lessens the long-term storage burden on L1 nodes. * **A New, Cheaper Data Market:** Blobs introduce their own independent fee market, distinct from the gas market for computation and standard calldata. This is a form of "multidimensional gas pricing." Blob gas is priced differently and, at present, is substantially cheaper than using an equivalent amount of calldata. * **Verification Without EVM Access:** A cornerstone of EIP-4844's design is that the L1 can verify the *availability* and *integrity* of blob data *without* the EVM needing to directly access or process the contents of the blobs themselves. In fact, the EVM *cannot* directly access blob data. This efficient verification is achieved through: * **KZG Commitments:** For each blob, a KZG (Kate-Zaverucha-Goldberg) commitment is generated. This is a type of polynomial commitment, serving as a small, fixed-size cryptographic proof (akin to a hash) that represents the entire blob. * **`BLOBHASH` Opcode:** A new EVM opcode, `BLOBHASH`, was introduced. This opcode allows smart contracts on L1 to retrieve the KZG commitment (the hash) of a blob associated with the current transaction. * **Point Evaluation Precompile:** A new precompiled contract enables the verification of blob data. A smart contract can call this precompile, providing a KZG commitment and a proof (submitted as part of the L1 transaction). The precompile then cryptographically verifies that the provided proof is valid for the given commitment, thereby confirming the integrity and availability of the original blob data without the EVM ever needing to "see" the raw blob. ## Blobs in Action: A Practical Walkthrough The introduction of blob transactions has streamlined how L2 rollups interact with the L1. **The Rollup Process with Blobs:** 1. The L2 rollup executes transactions, batches them, and compresses the data. 2. The rollup submits a Type 3 (blob) transaction to the L1. This transaction includes: * Standard transaction fields (sender, recipient, value, gas fees, etc.). * The KZG commitments (hashes) for each accompanying blob. * Proofs related to these commitments (for verification via the Point Evaluation Precompile). * References to the actual blob data, which is propagated through the consensus layer network, not the execution layer. 3. On L1, the rollup's smart contract (often an "inbox" contract) uses the `BLOBHASH` opcode to get the expected KZG commitment for a blob. 4. It then calls the Point Evaluation Precompile, passing the KZG commitment and the proof supplied in the transaction's `calldata`. 5. The precompile verifies the proof against the commitment. A successful verification confirms that the blob data referenced by the commitment was indeed available and unaltered when the transaction was included in a block. 6. After the data availability window expires, the blob data itself is pruned by L1 nodes, while the record of its commitment and successful verification remains permanent. **Etherscan Example: Witnessing Blobs in the Wild** Block explorers like Etherscan provide visibility into these new transaction types. For instance, examining a transaction from a rollup like ZK Sync that utilizes EIP-4844 would reveal: * `Txn Type: 3 (EIP-4844)` clearly indicated. * A "Blobs" tab or section, listing the KZG commitments (often displayed as hashes) of the blobs associated with the transaction. * Viewing the raw data of a blob would show a large hexadecimal string, representing the 128 KiB of data. * Crucially, Etherscan often provides a gas cost comparison, showing `Blob Gas Used` versus what the cost *would have been* if the same data had been posted as `Calldata Gas`. This frequently demonstrates massive cost savings, potentially reducing data posting costs by orders of magnitude compared to the old calldata method. Transaction debugging tools like Tenderly can offer even deeper insights, showing internal function calls within the L1 contracts, such as those interacting with the `BLOBHASH` opcode and the Point Evaluation Precompile. ## Sending Your Own Blob Transaction: A Developer's Glimpse For developers looking to interact with blobs directly, libraries like Web3.py (in Python) provide the necessary tools. Here's a conceptual overview based on a typical script for sending a blob transaction: 1. **Setup:** * Import necessary libraries (e.g., `Web3`, `eth_abi`). * Configure connection to an Ethereum node (RPC URL) and load the sender's account (private key). 2. **Blob Data Preparation:** * Define the data you want to include in the blob (e.g., a simple text string like `<( o.o )>`). * This data typically needs to be ABI-encoded. * **Crucial Padding:** Blobs *must* be exactly 128 KiB (4096 fields * 32 bytes/field). If your data is smaller, it must be padded, usually with null bytes (`\x00`), to reach this fixed size. ```python # Example: Encoded text is 'encoded_text' # Blob data must be comprised of 4096 32-byte field elements NUM_FIELD_ELEMENTS = 4096 BYTES_PER_FIELD_ELEMENT = 32 TARGET_BLOB_SIZE = NUM_FIELD_ELEMENTS * BYTES_PER_FIELD_ELEMENT encoded_bytes = encoded_text # Assuming encoded_text is bytes padding_needed = TARGET_BLOB_SIZE - len(encoded_bytes) # Blobs are typically constructed from 32-byte field elements. # A common practice is to pad at the beginning if the data is small, # or structure data into these 32-byte chunks. # For simplicity, if padding to the full 128KiB from arbitrary bytes: if padding_needed < 0: raise ValueError("Encoded data exceeds blob size limit") # A simple padding strategy (actual construction might be more nuanced # depending on how data is structured into field elements) blob_data_bytes = encoded_bytes + (b'\x00' * padding_needed) ``` *(Note: The video's example `BLOB_DATA = (b'\x00' * 32 * (4096 - len(encoded_text) // 32)) + encoded_text` suggests a specific way of organizing data into 32-byte chunks and then padding the remaining chunks. The core idea is achieving the exact 128 KiB size.)* 3. **Transaction Construction:** * Get the sender account object. * Create the transaction dictionary. Key fields specific to blob transactions include: * `'type': '0x3'` or `3`: Specifies it's an EIP-4844 blob transaction. * `'maxFeePerBlobGas'`: Sets the maximum price you're willing to pay per unit of blob gas. This operates on the separate blob gas fee market. * Other standard fields: `chainId`, `from`, `to`, `value`, `maxFeePerGas` (for L1 execution gas), `maxPriorityFeePerGas` (for L1 execution priority), `nonce`. 4. **Signing and Sending:** * Estimate the regular L1 execution gas for the transaction (`w3.eth.estimate_gas(tx)`). * Add this gas estimate to the transaction dictionary. * Sign the transaction. This is where the blob data itself is provided. The Web3.py library, when interacting with a supporting Ethereum node, handles the complex parts of generating the KZG commitments and proofs for the provided blob data. ```python # 'acct' is the account object, 'tx' is the transaction dictionary # 'blob_data_bytes' is the prepared 128 KiB blob data signed_tx = acct.sign_transaction(tx, blobs=[blob_data_bytes]) ``` * Send the signed raw transaction (`w3.eth.send_raw_transaction(signed_tx.rawTransaction)`). * Wait for the transaction receipt (`w3.eth.wait_for_transaction_receipt(tx_hash)`). Executing such a script, perhaps against a local development node like Anvil, will result in a Type 3 transaction being broadcast, carrying your data within a blob. ## Proto-Danksharding vs. Full Danksharding: The Path Ahead EIP-4844, or Proto-Danksharding, is a critical foundational step. It implements the necessary transaction format, fee market mechanics, and verification logic (KZG commitments, precompiles) for blobs. However, it is an intermediate stage. The "full" vision of Danksharding, planned for future Ethereum upgrades, aims to: * Significantly increase the number of blobs that can be included per block (e.g., from a target of 3 and max of 6 in Proto-Danksharding to potentially 64 or more). * Likely incorporate advanced techniques like Data Availability Sampling (DAS), allowing nodes to verify blob availability even more efficiently without needing to download all blob data. Proto-Danksharding lays all the groundwork, allowing the ecosystem to adapt to blob transactions while the full scaling solution is developed. ## Key Takeaways: What to Remember About EIP-4844 EIP-4844 and blob transactions represent a paradigm shift in how Ethereum handles large data payloads, especially for L2 rollups. Here are the essential points: * **Temporary & Pruned:** Blob data is not stored permanently on L1; it's available for a limited time (approx. 18 days) and then pruned. * **EVM Inaccessible:** The EVM cannot directly read or process the contents of blobs. Verification happens via cryptographic commitments (KZGs). * **Fixed Size:** Blobs have a strict, fixed size of 128 KiB. Data must be padded if smaller. * **Type 3 Transactions:** Blob-carrying transactions are designated as Type 3. * **Separate Fee Market:** Blobs utilize a distinct fee market with `maxFeePerBlobGas`, enabling cheaper data posting than traditional `calldata`. * **Library Support:** Client libraries (like Web3.py) and nodes abstract away the complexity of KZG commitment and proof generation when sending blob transactions. * **Foundation for Full Danksharding:** Proto-Danksharding (EIP-4844) is the necessary precursor to achieving the more extensive scalability benefits promised by full Danksharding. By dramatically reducing the cost of L1 data availability for rollups, EIP-4844 significantly enhances Ethereum's scalability, making L2 solutions more efficient and affordable, and paving the way for a more scalable and user-friendly Ethereum ecosystem. For further in-depth understanding, the official EIP-4844 specification and resources on Ethereum.org regarding Danksharding are highly recommended.