Optimize Reth execution with native KZG and BLS12-381 acceleration

[hero78119]

Objective

Reduce Reth guest execution cycles and shard count by adding Ceno-native acceleration for KZG proof verification and the underlying BLS12-381 operations.

Measured result

Ethereum mainnet block 25580200 was executed in Ceno and OpenVM without proof generation or verification. Both executions produced block hash:

34439c597563024690ce3c91a082c34507569c7e18cc4d1b3b68550b791a2773

VM	Guest instructions	Reported cycles	Execution time
OpenVM	533,937,048	533,937,048 instruction cycles	4.04 s interpreted; 1.50 s AOT execution
Ceno	1,085,866,491	4,343,465,968 subcycles	40.89 s AOT preflight

Ceno executed 551,929,443 additional guest instructions, or 2.034 times the OpenVM instruction count. Ceno's cycle count is effectively four subcycles per guest instruction, so guest instruction counts are the comparable measure.

With a 4.4 billion max-cell cap, the Ceno preflight produced:

• 38 shards
• 566,639,246 fallback steps, representing 52.18% of execution

The high shard count also increases cross-shard memory traffic and the resulting ShardRAM circuit size.

Workload evidence

Block 25580200 contains one blob transaction with one blob, requiring one KZG point-evaluation proof verification during block execution.

OpenVM's crypto provider implements optimized paths for:

• KZG proof verification
• BLS12-381 G1 addition and MSM
• BLS12-381 G2 addition and MSM
• BLS12-381 pairing
• BLS12-381 base-field and extension-field operations
• specialized modular arithmetic

The OpenVM metered execution contained approximately 525,000 field-expression rows, 770,000 modular-equality rows, and explicit 48-byte field-operation rows. These are AIR rows rather than one-to-one opcode counts, but they confirm use of the configured BLS12-381 arithmetic extensions.

Ceno's current Reth Crypto implementation overrides SHA-256, BN254, secp256k1, and secp256r1 operations. It does not override verify_kzg_proof, the BLS12-381 operations, or BLS12-381 pairing. No KZG or BLS12-381 ecall appeared in the Ceno chip assignments. The corresponding work therefore executes as ordinary RV32 guest instructions, producing a large population of ALU, load/store, and multiplication operations.

This missing KZG/BLS12-381 acceleration is the primary block-specific explanation for the approximately 552 million instruction gap.

Proposed work

1. Add the required BLS12-381 field and extension-field syscall/circuit support.
2. Add G1/G2 point-operation and pairing support needed by KZG verification.
3. Implement a Ceno verify_kzg_proof crypto-provider override backed by those operations.
4. Route Reth KZG point evaluation through the optimized implementation.
5. Add opcode/ecall accounting sufficient to confirm that KZG verification no longer falls back to an RV32 implementation.

EIP-2537 BLS precompile overrides and broader modular-exponentiation acceleration may be handled in the same implementation or as follow-up work. The first target should be the KZG verification path exercised by this block.

Acceptance criteria

• Valid and invalid KZG proof test vectors match the native/reference implementation.
• Existing BLS12-381 field, group, and pairing tests pass.
• Reth block 25580200 produces the expected block hash above in execute-only mode.
• The execution histogram shows the KZG/BLS12-381 optimized path instead of pure RV32 fallback.
• Ceno guest instructions, AOT fallback steps, and shard count for block 25580200 are reported before and after the change.
• The resulting instruction count is materially closer to the measured OpenVM baseline of 533,937,048 instructions.
• Existing Reth benchmark blocks remain correct.

No proof generation is required for the initial cycle-count comparison. A subsequent GPU proof run should validate the expected reduction in shard count and ShardRAM pressure.