Hello there,
I’d like to propose a solution for KZG multi-point evaluation that utilizes the EIP-2537 precompiles(live since Pectra) for cheaper execution.
Today, rollups and DA-checking contracts that verify multiple blob openings do so by looping the EIP-4844 0x0A point-evaluation precompile. This results in the following gas spending formula: overhead + n * 50_000, where n is the number of openings. For rollups already at N=6 (today’s cap), this is ~300k gas per settlement.
The EIP-2537 introduces the BLS12-381 curve operations precompiles; we need to replace the N independent pairing checks with one batched pairing check via a standard Fiat-Shamir random linear combination. This approach gradually reduces gas consumption, proportionally to the number of openings to be checked, up to a drastic reduction of ~70%.
The approach - Given N opening claims (C_i, z, y_i, π_i):
1. Derive challenge weights r_i = H(seed, i) mod q where seed = keccak256(all inputs).
2. Compute RHS = Σ r_i · π_i via one G1MSM call (0x0C).
3. Compute LHS = Σ r_i · C_i + z · RHS − (Σ r_i · y_i) · G₁ via one more G1MSM call (0x0C). The shared z lets us fold the z·π_i terms into a single MSM slot via (RHS, z), shrinking the LHS from 2N+1 to N+2 slots.
4. Verify e(LHS, −G₂) · e(RHS, [τ]₂) = 1 via one PAIRING_CHECK call (0x0F).
Total: 2 G1MSMs + 1 pairing check, regardless of N.
An invalid batch passes with probability ≤ N/q ≈ 2⁻²⁵² for BLS12-381’s scalar field — negligible by Schwartz–Zippel. Also, the technique requires embedding [τ]₂, the second G2 monomial point from the Ethereum KZG trusted setup ceremony, as a contract constant for the final pairing check. This is a publicly available value from the ceremony output.
My collaborator @conache and I have developed a prototype of this solution inside of Blober - our blob handling and verification library - and the repository itself shows the related statistics and benefits of our approach.
Running benchmarks on our approach led us to discover a threshold point of N=5. Past this threshold, our approach in multi-point validation is less expensive than the iterative approach (from 11% to ~70% less expensive, depending on the value of N). Below the threshold, the library falls back to the standard iterative approach as the batched path’s fixed overhead isn’t yet amortized.
Upon reaching the forum, we noticed the EIP-8149, which suggests a new precompile for the multi-point single-blob case. This proposes a precompile for the multi-point case, but requires the prover to switch to a new combined-proof format. Our approach doesn’t require a prover-side change, because it batches the standard per-point proofs that c-kzg already emits. Additionally, it covers the multi-blob shared-z case that is not addressed in EIP-8149, and can be shipped to mainnet without any protocol change.
One of the points open to discussion is that EIP-2537 accepts only 128-byte uncompressed points. The existing rollup pipelines currently work with 48-byte compressed form. Through our research, we figured out that this tradeoff is heavily outweighed by the benefits of the solution in terms of gas usage. We also assume that parties that provide points in compressed format also initially had them in the uncompressed format, so it should not be an issue to provide them. On-chain decompression also happens to be execution-heavy, so it makes the most sense to accept the points in the uncompressed format.
We are more than open to discussing any potential improvements to this solution, any issues, or anything that comes to mind. Looking forward to feedback. If there is interest in this solution, we will formalize it as an Informational EIP with the full specification, security proof, and benchmark methodology.