Split out of the zkEVM tracking issue.
What
On the eth-act witness dashboard (zkevm-benchmark-workload/stateless-validator, tests-zkevm@v0.6.2), ethrex_zisk-v1.0.0-alpha reports 26 failures. 22 of them are a ZisK defect, not ours.
All 22 crash identically:
Status: crashed
Crash reason: zkVM method error: Emulator panicked: called `Option::unwrap()` on a `None` value
Test families, all small blocks (34,821–293,760 gas):
prague_eip2537_bls_12_381_precompiles_test_bls12_g1msm (×4)prague_eip2537_bls_12_381_precompiles_test_bls12_g1mul (×8)prague_eip2537_bls_12_381_precompiles_test_bls12_map_fp_to_g1 (×9)prague_eip2537_bls_12_381_precompiles_test_bls12_pairing (×1)
Why it is not ethrex
Two independent lines of evidence.
Another client fails the identical set. zesu_zisk-v1.0.0-alpha fails exactly 22, the same four families, with the same panic string — and nothing else. reth_zisk-v1.0.0-alpha hits them too, inside its larger set. Intersecting the failing test names across all three ZisK runs gives exactly these four families.
Our SP1 and ZisK guests run the same Rust. In crates/guest-program/stateless-validator/Cargo.toml:
sp1 = ["zkvm-interface"]
zisk = ["zkvm-interface", "ethrex-common/zisk"]
Both dispatch through src/crypto/zkvm_interface.rs, so bls12_381_g1_msm, bls12_381_fp_to_g1 and bls12_381_pairing_check are the same code on both. ethrex_sp1-v6.3.1 scores 19413 / 0 on the same suite. The only thing that differs is the syscall implementation underneath, which is ZisK's.
Action
File upstream against ZisK with the evidence above. Nothing to change in ethrex; this issue tracks the upstream fix landing and the dashboard going green.
Split out of the zkEVM tracking issue.
What
On the eth-act witness dashboard (
zkevm-benchmark-workload/stateless-validator,tests-zkevm@v0.6.2),ethrex_zisk-v1.0.0-alphareports 26 failures. 22 of them are a ZisK defect, not ours.All 22 crash identically:
Test families, all small blocks (34,821–293,760 gas):
prague_eip2537_bls_12_381_precompiles_test_bls12_g1msm(×4)prague_eip2537_bls_12_381_precompiles_test_bls12_g1mul(×8)prague_eip2537_bls_12_381_precompiles_test_bls12_map_fp_to_g1(×9)prague_eip2537_bls_12_381_precompiles_test_bls12_pairing(×1)Why it is not ethrex
Two independent lines of evidence.
Another client fails the identical set.
zesu_zisk-v1.0.0-alphafails exactly 22, the same four families, with the same panic string — and nothing else.reth_zisk-v1.0.0-alphahits them too, inside its larger set. Intersecting the failing test names across all three ZisK runs gives exactly these four families.Our SP1 and ZisK guests run the same Rust. In
crates/guest-program/stateless-validator/Cargo.toml:Both dispatch through
src/crypto/zkvm_interface.rs, sobls12_381_g1_msm,bls12_381_fp_to_g1andbls12_381_pairing_checkare the same code on both.ethrex_sp1-v6.3.1scores 19413 / 0 on the same suite. The only thing that differs is the syscall implementation underneath, which is ZisK's.Action
File upstream against ZisK with the evidence above. Nothing to change in ethrex; this issue tracks the upstream fix landing and the dashboard going green.