Introduction:
In the world of blockchain technology, Ethereum has been actively working on solutions to accommodate its expanding user base, enhance transaction throughput, and reduce costs. To facilitate long-term scalability, Ethereum has embraced the concept of data sharding. As part of this journey towards full sharding, Ethereum Improvement Proposal 4844 (EIP-4844) has been introduced. This proposal acts as a transitional step, aiming to prepare Ethereum for achieving a higher throughput of approximately 100,000 transactions per second (TPS) while maintaining security and decentralization.
Understanding EIP Standards and EIP-4844’s Significance:
Ethereum Improvement Proposals (EIPs) are formal documents that outline improvements, new features, or changes to the Ethereum protocol. They serve as a means for Ethereum’s community members to propose and discuss potential enhancements.
EIP-4844 specifically focuses on integrating shard blob transactions within the Ethereum network. Sharding involves dividing databases into smaller partitions, called shards, to improve efficiency and performance. By implementing shard blob transactions, Ethereum aims to enhance transaction costs and increase overall throughput. Although EIP-4844 is not a complete sharding solution, it represents a significant step towards achieving the necessary scalability and cost-effectiveness for broader adoption.
What to Expect from This Article:
This article will delve into the details of EIP-4844 and its impact on Ethereum’s scalability. We will explain the concept of sharding, provide insights into the role of EIP standards, and elucidate the significance of shard blob transactions within the Ethereum ecosystem. Additionally, we will explore the key features and mechanisms introduced by EIP-4844, including blob-carrying transactions, gas accounting, and the relationship between EIP-4844 and full sharding. By the end of this article, you will have a comprehensive understanding of EIP-4844 and how it contributes to Ethereum’s ongoing efforts to improve scalability and reduce transaction costs.
Through this exploration, you will gain insights into:
- The concept of sharding and its significance for enhancing Ethereum’s scalability.
- The role of EIP-4844 as an intermediate step towards full sharding.
- The features and mechanisms introduced by EIP-4844, such as blob-carrying transactions and gas accounting.
- How EIP-4844 aligns with Ethereum’s roadmap for scalability and cost reduction.
- The potential benefits users can expect from implementing EIP-4844 include faster transactions and lower fees.
By the end of this article, you will be well-equipped to understand and appreciate the significance of EIP-4844 and its impact on Ethereum’s journey toward achieving greater scalability and mass adoption.
What Is EIP-4844?
EIP-4844 specifically focuses on integrating shard blob transactions within the Ethereum network. Sharding involves dividing databases into smaller partitions, called shards, to improve efficiency and performance. Sharding involves partitioning databases into smaller segments, enhancing their efficiency and performance. In the context of Ethereum, sharding aims to improve transaction costs and increase throughput. Ethereum plans to implement dank sharding, a specific type of sharding, which is expected to significantly increase Ethereum’s TPS to approximately 100,000.
Danksharding introduces several innovations compared to previous Ethereum and non-Ethereum sharding proposals. It focuses on providing more space for blobs of data instead of transactions. Additionally, danksharding implements a merged fee market where one proposer selects transactions for all shards, eliminating the need for each shard to have its own proposer. To address the issue of maximal extractable value (MEV), a proposer/builder separation method is also introduced.
EIP-4844 (Proto-Danksharding)
EIP-4844, also known as proto-dank sharding, serves as an intermediate step towards full dank sharding. It aims to increase TPS to approximately 1,000 and introduces a new transaction type called “blob-carrying transactions.” These transactions include “blobs” of data, a crucial element for achieving full danksharding. The implementation of EIP-4844 is expected in the second half of 2023, though delays may occur.
How Does EIP-4844 Work?
EIP-4844 introduces blob-carrying transactions, which are similar to regular transactions but with the addition of binary large objects known as “blobs.” These blobs are attached to blocks, increasing the data capacity of blob-carrying blocks. Notably, the inclusion of blobs differs from simply increasing block sizes, which Ethereum avoids due to concerns regarding centralization and computational requirements.
Blobs have distinct characteristics compared to blocks. While blocks are stored indefinitely and visible to the Ethereum Virtual Machine (EVM), blobs have a limited lifespan and are not visible to the EVM. Blobs reside on the Ethereum consensus layer, rather than the execution layer, resulting in cheaper storage costs. EIP-4844 also encompasses execution-layer logic, verification rules, multi-dimensional fee markets, and other system changes necessary for full danksharding in the future.
It’s important to note that EIP-4844 does not implement actual sharding but brings Ethereum closer to achieving the necessary scalability and cost levels for widespread adoption. Despite not achieving full danksharding, EIP-4844 still provides scalability and cost-saving benefits.
How Will EIP-4844 Benefit Users?
EIP-4844 is a protocol upgrade aligned with Ethereum’s rollup-centric roadmap. The preparation for its implementation is progressing rapidly, with devnets already running and the upgrade’s specifications nearing finalization.
Users can expect noticeable improvements after EIP-4844’s implementation, primarily in the form of faster transactions and lower fees. Successful implementation will also enhance Ethereum’s competitiveness in the cryptocurrency space.
For users concerned about accessing old blob data that has been deleted, it’s important to note that while blobs are deleted after weeks, their data should still be available in longer-term storage maintained by the Ethereum consensus layer.
Blob Transaction
EIP-4844 introduces a new transaction type, “blob transaction,” based on the EIP-2718 standard. The TransactionType for a blob transaction is BLOB_TX_TYPE, and the TransactionPayload is the RLP serialization of the TransactionPayloadBody, which includes various fields such as chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_data_gas, blob_versioned_hashes, y_parity, r, and s.
The blob transaction differs from a regular create transaction as the “to” field must represent a 20-byte address and cannot be nil.
The EIP-2718 ReceiptPayload for a blob transaction consists of status, cumulative_transaction_gas_used, logs_bloom, and logs, encoded as RLP.
Blob Transaction Format:
| Field | Description |
| TransactionType | BLOB_TX_TYPE |
| TransactionPayload | RLP serialization of TransactionPayloadBody |
Signature
The signature values y_parity, r, and s for a blob transaction are calculated by constructing a secp256k1 signature over a specific digest. The digest is obtained by hashing the concatenation of BLOB_TX_TYPE and the RLP serialization of chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_data_gas, and blob_versioned_hashes using the keccak256 hashing algorithm.
Signature Calculation:
digest = keccak256(BLOB_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_data_gas, blob_versioned_hashes]))
signature = secp256k1_sign(digest, private_key)
y_parity, r, s = extract_signature_parts(signature)Header Extension
EIP-4844 extends the current header encoding by introducing two new 64-bit unsigned integer fields: data_gas_used and excess_data_gas. The data_gas_used field represents the total amount of data gas consumed by the transactions within the block. The excess_data_gas field tracks the running total of data gas consumed above the target, bounded at 0. Blocks exceeding the target data gas consumption increase the excess_data_gas value, while blocks below the target decrease it.
Header Encoding:
| Field | Description |
| data_gas_used | Total data gas consumed by transactions within the block |
| excess_data_gas | Running total of excess data gas consumption prior to the block (bounded at 0) |
Opcode to Get Versioned Hashes
EIP-4844 introduces a new opcode called BLOBHASH (with the opcode HASH_OPCODE_BYTE) to obtain versioned hashes. This opcode reads an index as a big-endian uint256 from the stack, replacing it with tx.blob_versioned_hashes[index] if index is within the range of the blob_versioned_hashes list. Otherwise, it replaces the index with a zeroed bytes32 value. The opcode incurs a gas cost defined as HASH_OPCODE_GAS.
BLOBHASH Opcode:
| Opcode | Description |
| BLOBHASH | Reads an index from the stack and replaces it with the corresponding versioned hash |
Point Evaluation Precompile
A new precompile, located at POINT_EVALUATION_PRECOMPILE_ADDRESS, is introduced to verify a KZG proof. This proof demonstrates that a blob, represented by a commitment, evaluates to a given value at a specific point. The precompile, executed with the POINT_EVALUATION_PRECOMPILE_GAS cost, verifies the commitment’s association with the provided versioned_hash and validates the KZG proof using the commitment, point, and proof values.
Point Evaluation Precompile:
def point_evaluation_precompile(input: Bytes) -> Bytes:
versioned_hash = input[:32]
z = input[32:64]
y = input[64:96]
commitment = input[96:144]
proof = input[144:192]
assert kzg_to_versioned_hash(commitment) == versioned_hash
assert verify_kzg_proof(commitment, z, y, proof)
return Bytes(U256(FIELD_ELEMENTS_PER_BLOB).to_be_bytes32() + U256(BLS_MODULUS).to_be_bytes32())Gas Accounting
EIP-4844 introduces data gas as a new type independent of normal gas. Similar to EIP-1559, data gas follows its own targeting rule. The excess_data_gas header field stores persistent data required to compute the data gas price. Currently, only blobs are priced in data gas.
Gas Accounting Formulas:
data_fee = calc_data_fee(header, tx)
total_data_gas = get_total_data_gas(tx)
data_gasprice = get_data_gasprice(header)
calc_data_fee(header, tx) = get_total_data_gas(tx) * get_data_gasprice(header)
get_total_data_gas(tx) = DATA_GAS_PER_BLOB * len(tx.blob_versioned_hashes)
get_data_gasprice(header) = fake_exponential(MIN_DATA_GASPRICE, header.excess_data_gas, DATA_GASPRICE_UPDATE_FRACTION)Consensus Layer Validation
In the consensus layer, blobs are referenced but not fully encoded within the beacon block body. Instead, they are propagated as “sidecars.” The consensus layer ensures the availability of blobs and handles the processing of updated beacon blocks, gossiping and syncing beacon block types and new blob sidecars, and producing beacon blocks with associated blob sidecars.
Execution Layer Validation
The execution layer enforces the validity conditions of a block, including the updating of excess_data_gas, sufficient balance for blob transactions, the presence of at least one blob, verification of versioned blob hashes, confirmation of meeting the current data gas price, tracking total data gas spent, and enforcing the maximum data gas per block limit.
Networking
Blob transactions have two network representations: PooledTransactions and BlockBodies. PooledTransactions use a wrapped format that includes the EIP-2718 TransactionPayload, blobs, commitments, and proofs. These elements encapsulate the necessary data for validating blob transactions. BlockBodies, used for body retrieval responses, follow the standard EIP-2718 blob transaction TransactionPayload format.
Nodes do not automatically broadcast blob transactions to their peers. Instead, these transactions are announced using NewPooledTransactionHashes messages and can be manually requested using GetPooledTransactions.
Conclusion
EIP-4844 is a crucial step towards full sharding, aligning with Ethereum’s objective of providing temporary scaling relief for rollups. By introducing blob transactions in the expected format of the final sharding specification, EIP-4844 allows rollups to scale up to 0.375 MB per slot. It establishes a separate fee market to keep fees low during limited usage of the system.
The design of EIP-4844 balances the implementation effort between achieving immediate results and minimizing future development burdens. It significantly progresses the work required for full sharding, including a new transaction type, execution-layer logic, consensus cross-verification, beacon block logic, and self-adjusting independent gas pricing for blobs.
Further work towards full sharding includes extensions for 2D sampling, data availability sampling implementation, proposer/builder separation, and proof of custody requirements for validators.
EIP-4844 also paves the way for future protocol enhancements and cleanups, such as applying its gas price update rule to the primary basefee calculation.
