L1-zkEVM Breakout #002

zkGM

Reacted to "zkGM" with 🔥

Reacted to "zkGM" with 🔥

love that font @Kevaundray Wedderburn

Reacted to "love that font @Keva..." with ➕

Reacted to "love that font @Keva…" with ➕

Reacted to "zkGM" with 🔥

Are there OS level tweaks built in?

Have you talked with Go Ethereum team for ZK proving GETH?

Replying to "Are there OS level..." *HW/target level

nope

Reacted to "nope" with 👍

any major tradeoffs comapred to regular go?

Can you share slides?

Reacted to "Can you share slides..." with ➕

Replying to "Have you talked with..." https://github.com/eth-act/skunkworks-tama/tree/kw/develop

https://github.com/abarisani/abarisani.github.io/tree/master/research/tamago

Reacted to "nope" with 😮

Slides

rv64cfimsu

Any plans to target WASM?

wasm is already supported by Go

https://go.dev/wiki/WebAssembly

Replying to "Any plans to target ..." Do you mean wasm32-unknown or with wasi?

There is an initiative to move to REST and SSZ on engine API

Replying to "Any plans to target ..." We didn’t have time to go into it, but we also tried Go -> WASM -> C -> RISCV64 and Tamago seems to be the most performant

Replying to "Any plans to target ..." wasm32-unknown

Reacted to "We didn’t have time ..." with 👍

Reacted to "wasm32-unknown" with 👍

Reacted to "There is an initiati..." with 👍

Reacted to "There is an initiati..." with 🙏

See here: https://github.com/ethereum/execution-apis/pull/764

Can you share slides? I just updated the deck at the link I shared earlier. For any further questions please email me, happy to help.

and bugs

Reacted to "Can you share slides..." with 🙏

Can you review Nethermind implementation?

Replying to "Can you review Nethe..." I started looking into it a few days ago

Reacted to "I started looking in..." with 🙏

Are you planning on supporting EIPs 7708, 7778, and 7843 in the new spec tests? I’ve been integrating them with ethrex and made ~13 of them pass by “disabling” those EIPs

can you post the link to the spec?

https://github.com/ethereum/execution-spec-tests/releases/tag/zkevm%40v0.2.0 if I’m not mistaken

Replying to "can you post the lin..." Yep this is correct

Replying to "can you post the lin..." We use the projects/zkevm branch on the execution-specs repo: https://github.com/ethereum/execution-specs/tree/projects/zkevm

link to guest spec?

Is there any guest program tests at all, other than EESTs at the moment?

Replying to "link to guest spec?" Its in the execution specs repo here: https://github.com/ethereum/execution-specs/blob/1d98b55a4a5d0615bca62ec69b308096059f6c06/src/ethereum/forks/amsterdam/stateless_guest.py#L33

@kev i believe all the links to the slides, specs, etc. will be provided after the call like the last time, right?

ssz neutral == 😂

Replying to "Is there any guest p..." Can you clarify what would need to be added?

Reacted to "ssz neutral == 😂" with 😁

Zilkworm uses RLP

Replying to "@kev i believe all t..." Yep, it will be on the issue

Replying to "Zilkworm uses RLP" zevm-stateless, besu zig guest is using rlp also

Replying to "Zilkworm uses RLP" What is being RLP’d?

Replying to "Zilkworm uses RLP" stateless_input

Replying to "Zilkworm uses RLP" Nethermind is currently using RLP

Replying to "Zilkworm uses RLP" The witness + block data

chain id as input helps with native rollups

Reacted to "Yep, it will be on..." with 👍

Reacted to "chain id as input he..." with ❤️

Replying to "Zilkworm uses RLP" We can benchmark concretely with zkVMs,ssz was more performant outside of circuit. I don’t think we have a strong bias towards ssz or rlp

Reacted to "chain id as input he..." with ❤️

historically ELs do not have a complete-enough SSZ implementation

we have to go with something platform/library independent

Reacted to "historically ELs d..." with ➕

Reacted to "historically ELs do ..." with ➕

Replying to "Zilkworm uses RLP" RLP should be slower, but it's the EL standard now. We plan on switching to something faster (not ssz)

Replying to "historically ELs do ..." Yes, this is true. Although this other chats of potentially supporting SSZ in EngineAPI might give more reason on maybe trying to support it

Replying to "Zilkworm uses RLP" I don’t think we can standardize on something that is not rlp or ssz because every EL will need to support it

Replying to "historically ELs do ..." if ssz engine api makes it into a fork, definitely that should resolve it. I wasn’t expecting that to actually make it into a fork though

Replying to "Zilkworm uses RLP" Maybe message pack? But I think we should benchmark because it could be a micro optimization that is not needed

Reacted to "we have to go with s..." with 👍

Reacted to "we have to go with s..." with 👍

Replying to "Zilkworm uses RLP" https://xkcd.com/927/

Reacted to "https://xkcd.com/927..." with 😁

Reacted to "I don’t think we can..." with 👍

Replying to "Zilkworm uses RLP" Transport protocol doesn’t necessarily have to follow the same encoding as zkvm input, however it may make sense to do so.

Reacted to "I don’t think we can..." with 👍

Reacted to "Transport protocol..." with 👍

Reacted to "Transport protocol d..." with 👍

Reacted to "Transport protocol d..." with 👍

How much effort would be for ZKVms to support F and D RISC-V instructions? A big effort? Just curiosity

Replying to "Zilkworm uses RLP" We put in RLP, speculating on the standards. But as of today the pre-processing is a reality and we can just do something way faster with the pre-processing. The JSON-RPC can and should be replaced with RLP or ssz and we can tweak it further

That’s why there is also the info in metadata

Would we need a MetadataV4 for that?

Replying to "That’s why there is ..." It’s already done if I’m not wrong

Replying to "That’s why there is ..." here

Replying to "That’s why there is ..." https://github.com/ethereum/consensus-specs/pull/4877

Replying to "That’s why there is ..." You mean for 8025?

Replying to "That’s why there is ..." yes

Replying to "That’s why there is ..." Ah yeah, I think the idea is that with ExecutionProofStatus, we would not upgrade the version

Introducing a new version touches pre-existing codepaths and adds complexity because peers would have to use different versions of the existing status type for different peers. I think its cleaner to have things decoupled into a separate rpc @Manu

I need to go, thanks for the opportunity of presenting TamaGo. Again email me for any questions, happy to help, I think it would be a very interesting use case for it. Cheers.

We also have been analysing what precompiles we can turn into evm bytecode. Currently doing some analysis to see how often the precompiles are being used. The main issue right now is modexp imo

Reacted to "I need to go, thanks..." with 🙏

Reacted to "I need to go, than..." with 🙏

Reacted to "We also have been ..." with 👍

https://codygunton.github.io/talks-and-writing/2026-03-11-zkevm-breakout/

Slides for Proj 1, 2 and 6: https://docs.google.com/presentation/d/1fmSZYyp8SNl3FHw4JQGAz1Ik0gQlfq6XEYcV1xLPChc/edit?usp=sharing

Slide for project 5 https://docs.google.com/presentation/d/1Iw5RqCIrhvhmAWUl9UjAS9I1zSq1Lr50YVukGMqmqp0/edit?usp=sharing