feat: update ere

[han0110]

• Dependencies
  • Bump stateless to paradigmxyz/stateless
  • Bump ethrex to v19.0.0
  • Bump ere to have openvm@v2.0 with 256 bytes public values (configured by ere), and sp1 with zkvm-standards impl
• Guests
  • ethrex and reth guests now output stateless_output_bytes instead of hash, since openvm and zisk they both support up to 256 bytes now (and sp1 doesn't have limitation). And zesu and nethermind both output stateless_output_bytes, so the released guests are at least compatible on V4 payload fixtures (Amsterdam).
  • Drop airbender and risc0 guests
  • Add ethrex-openvm guest
  • Use zkvm-interface crypto impl for sp1 guests
  • Bump republished zesu-zisk to zisk@v1.0.0-alpha (only support V4 payload).
  • Add republished nethermind-zisk (support V3 payload by tweaking the schema id to 0x0000)
• CI uses the artifact-registry.json as the single source of truth to do the republish (read the json and generate job matrix).

---

The blockers of linking guest lib and zkVM lib:

• zisk - The lib currently does allocation, but will be fixed in the next release (fixed by Feature/ziskos isolated allocator 0xPolygonHermez/zisk#1157)
• sp1 - Same and will require some more changes in upstream to avoid the allocation.

So after zisk@v1.0.0-beta is released, we should be able to link zesu with zisk with a small shim (which relaxes the zkVM version matching a bit, and we only need to select the right EL version).

[jsign]

Nice! LGTM! Left some comments for your consideration, but nothing blocking.

[jsign]

Just to check if I understand correctly: this is just to adjust a naming mismatch between what extern keccak func Reth wants in their Crypto trait with the naming that we use in zkevm_interface (and SP1 sticks to). No?

[han0110]

This is a leaking from the Reth that zkvm-standards didn't cover, in alloy-primitives if we don't want to patch the crate (sha3 or tiny-keccak), we need to provide this native_keccak256 so alloy-primitives routes the keccak256 to it, and SP1's zkvm-interface impl doesn't contains that, so we need to patch it here (ZisK doesn't need one because ziskos exposes one)

If stateless repo eventually publishes a rellocatable ELF, this should be move to there so the ELF doesn't depend on symbol outside zkvm-standards

[jsign]

Uhm, I see. Technically in the spec 0x0000 is not a valid value (was done intentionally to avoid mistakes i.e. avoiding default values just in case).

But I guess Nethermind assumed 0x0000 was for Fulu (since we started in the spec in Glamsterdam).

Is this correct?

I could meditate change 0x0002 for Glamsterdam and leave 0x0001 for Fulu so we can prove mainnet blocks.

Not a huge deal now. LMK your thoughts and if I'm understanding the situation correctly.

[han0110]

But I guess Nethermind assumed 0x0000 was for Fulu (since we started in the spec in Glamsterdam).

Yes

I could meditate change 0x0002 for Glamsterdam and leave 0x0001 for Fulu so we can prove mainnet blocks.

I'm not sure in which case we'd bump the schema id, but if it's going to be bumped for each fork, leaving 0x0001 for Fulu and lifting Glamsterdam to 0x0002 sounds good to me (tho not sure if it's worth doing so since the Glamsterdam will land soon and Fulu support might not be necessary)

[jsign]

Uhm, yeah agree. Maybe better keep Glamsterdam = 0x0001 and keep schema-id as a structural signal of things rather than forks. At least that was my original intention, since for forks we already have ChainConfig.

So a bit two orthogonal things -- no need to get distracted by this 0x0000 ad-hoc value usage.

[han0110]

Yeah agree, even without the schema id hint, I think the guest can still decode the ExecutionPayload correctly by the fork passed in (I did that in e0567c3).

[jsign]

Yeah, maybe that's simpler for guest programs instead of the SSZ "magic" of reading some fields first as that commit.

So schema-id might end up being fork attached (plus potentially encoding attached, but doubt usage of this dimension will happen soon really; mostly a future proof thing that we won't be touching much reg encodings or extra stateless input fields for same fork)