Morph: EIP-4844 zkEVM and Aggregated Proof Integration Solution
TechFlow Selected TechFlow Selected
Morph: EIP-4844 zkEVM and Aggregated Proof Integration Solution
This paper proposes a practical and efficient circuit design scheme under the EIP-4844 proposal.
Navigating Web3 tides with focused insightsAuthor: Morph
Background
EIP-4844 introduces a new transaction type called "Blob-carrying transactions," which include large amounts of data that cannot be accessed via EVM execution. However, commitments to these transactions can be accessed. This transaction type is designed to be fully compatible with the formats used in sharding schemes.
A Blob is a vector containing 4096 finite field elements (the finite field being the BLS12-381 scalar field). Mathematically, these 4096 finite field elements can interpolate a polynomial p(x) of degree 4095, whose value at wi equals the i-th finite field element.
Blob commitments are computed using KZG commitments and verified through corresponding verification methods.
Some constants introduced in EIP-4844:
EIP-4844 plays a crucial role in the Rollup process. Instead of placing Rollup data into transaction calldata, rollups aim for submitters to place data into blobs. This approach ensures data availability while reducing on-chain costs associated with extensive calldata usage. Rollups must guarantee data availability over a sufficiently long period so honest operators can construct state proofs, although this data does not need to persist indefinitely on-chain. ZK rollups will provide two types of commitments for their transactions or states: Blob commitments and zk proofs.
Equivalent Proof of EIP-4844 KZG Commitment
In current zero-knowledge proof circuit implementations, due to lack of support for complex non-native finite field operations such as bilinear pairings based on the BLS12-381 elliptic curve, the validation of Blob commitments is transformed into consistency checks on evaluations at arbitrary challenge points by leveraging the equivalence between polynomial evaluation consistency and commitment validity.
The consistency proof for EIP-4844 consists of three parts:
-
Proving consistency between raw transaction data in the Blob and its finite field elements via circuitry.
-
Using circuits to prove that the polynomial encoded by the finite field elements evaluates to y at challenge point x.
-
Using precompiled contracts to verify the relationship among commitment c, challenge value x, and polynomial evaluation y.
Verification of Consistency Between Raw Transaction Data and Blob
First, design a circuit to prove the correspondence between raw transaction data and finite field elements in the Blob. The inputs to this circuit are the raw transaction data and 4096 finite field elements. Constraints encode the computation logic, where encoding from raw transaction data to Blob follows this scheme:
-
Encode every 31 bytes of input data into 32 bytes representing one BLS12-381 scalar field element, ensuring encoded values remain within the scalar field modulus range. To support subsequent blob shard verification, input data in a batch (raw transaction information) is divided into chunks.
-
For each chunk's blob encoding, store the length of the input data in the first 4 bytes of the initial 31-byte segment. The first 27 bytes of the input data fragment are encoded into the remaining 27 bytes, forming the first finite field element (32 bytes total: first byte is 0, second to fourth bytes indicate input data length, remaining 27 bytes hold the first 27 bytes of data) in the chunk’s blob shard.
-
Subsequent input data in the chunk is split into 31-byte segments stored in 32-byte slots; if the final segment has fewer than 31 bytes, it is padded with zeros.
This encoding splits the batch length across multiple chunk lengths stored in each chunk's blob elements, facilitating future aggregatable designs.
Blob Polynomial Evaluation Verification
This circuit verifies that the polynomial p(x), derived from the Blob's finite field elements, evaluates to y at any given point (Challenge Point) x. By doing so, the otherwise unverifiable blob commitment under EIP-4844 becomes a verifiable triplet: challenge point x, evaluation result y, and commitment c. Inputs to this circuit are 4096 finite field elements and challenge point x; output is the evaluated result y.
The Blob polynomial evaluation primarily uses the Barycentric evaluation formula. For a Blob with 4096 finite field elements:
The evaluation formula is:
Consistency Verification Between Blob Commitment and Evaluation Result
Prior to this step, the consistency check between Blob and its commitment has been transformed into verifying consistency among challenge point x, function value y, and Blob commitment. With EIP-4844 support, smart contracts can access the Blob’s commitment, allowing this verification to be directly performed on-chain. Below, we discuss aggregation optimizations for the previous circuit-based evaluations.
Aggregatable Blob Verification Scheme
Each 32-byte segment in a Blob can represent one BLS12-381 scalar field element. However, original transaction data lengths vary, leading to several issues:
-
It's impossible to ensure that raw transaction data within a chunk is an integer multiple of 32 bytes, meaning transaction data may not perfectly align with an integer number of finite field elements.
-
Encoded transaction data might span across two Blobs.
-
After encoding, a Batch or chunk may occupy fewer than 4096 finite field elements, resulting in inefficient Blob space utilization.
To resolve the first issue, we pad each Chunk (corresponding transaction data) with zeros so that the number of finite field elements required to encode all transactions in a chunk becomes an integer. For the second issue, we enforce that no single transaction spans two Blobs and optimize multi-Blob handling using multi-point opening techniques for KZG commitments.
For the third issue, we propose a new aggregation scheme. We modify the original format—previously storing four bits of batch length in the first five bits—to instead store four bits of chunk length information in the first five bits of each shard. The rest of the encoding remains unchanged. Additionally, in the Chunk proof, besides consistency checks, we include index values indicating the positions (in terms of Blob elements) of the first and last transactions within that chunk.
Our solution offers the following advantages:
-
Compatibility: EIP-4844 uses Blob-data. Our scheme specifically implements the encoding process from raw transaction data to Blob-data, maintaining compatibility with existing ZKevm circuits.
-
Practicality: Ethereum precompiled contracts only support BN254. Validating KZG commitments using BLS12-381 would require numerous non-native scalar field computations (e.g., pairing operations), consuming excessive gas. Our use of the Barycentric formula significantly reduces cross-field computations, making actual computational load feasible.
-
Aggregatability: Aggregated proofs reduce the number of individual proofs and verification rounds, lowering on-chain gas consumption. Our scheme enhances aggregation at the chunk level, combining effectively with EIP-4844 to further reduce gas costs.
Conclusion
Layer-2 solutions play a vital role in Ethereum's scalability roadmap, yet they face debates around security and performance limitations. ZK-rollups leverage solid mathematical foundations, offering high security assurance, albeit with computational overhead in generating and verifying proofs. Through improved algorithms and hardware, proof generation costs can be significantly reduced; similarly, optimizing on-chain computation and storage logic can mitigate verification costs.
EIP-4844 acts as a catalyst for rollup solutions, greatly optimizing on-chain data storage gas costs while introducing practical challenges in implementation. This article presents a practical and efficient circuit design under the EIP-4844 proposal, effectively reducing gas consumption and addressing certain application-level issues arising from EIP-4844. The Morph team consistently strives to create a lower-cost, higher-security transaction ecosystem. Guided by this vision, we continue exploring new technologies and aim to contribute more to the community ecosystem.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@MorphLayer
