EVMMAX Implementers Call 1

[poojaranjan]

Meeting Info

Dec 05 , 12:00 UTC

Duration: 90 minutes

Zoom: Link

📅 Subscribe to the Ethereum Protocol Call calendar for calendar invites

Resources

• EVMMAX Breakout - Devcon SEA L1 R&D Workshop
• Prev meeting 15th Nov 2024 notes

Agenda

• Introduction. Who do we have on the call? What was done till now?
• Propose use cases of EVMMAX
• Discuss Poseidon hash in EVMMAX spec Sol impl Python impl
• jwasinger Comment

Please add other agenda items or links to discuss.

Next call on Jan 02, 2025

[rodiazet]

Proposed agenda points:

• Introduction. Who do we have on the call? What was done till now?
• Propose use cases of EVMMAX
• Discuss Poseidon hash in EVMMAX spec Sol impl Python impl

[jwasinger]

I would like to raise two points on the call:

• I updated EIP-6690 to reflect the draft spec that we've been discussing in the evmmax discord channel: https://eips.ethereum.org/EIPS/eip-6690 . I think there's still a lot of room for iteration here, but I took the liberty to update the existing spec to increase visibility into the current state of what's being considered EVMMAX spec. I have implemented the changes fully in Geth: [WIP] core/vm, params: Implement EIP-6690 go-ethereum#30840

• I cleaned up and documented a tool that I have used to write EVM contracts that utilize EIP-6690 to implement BLS G1/G2 add/mul as well as bls12381 base-field modular inverse: https://github.com/jwasinger/evmmax-bls12-381 . In the README on that repo, I've noted some improvements that I think would be necessary to improve the usefulness of this tool, and allow it to be viable for implementation of a wider range of crypto operations.

[poojaranjan]

EVMMAX Implementers Call Playlist

• Recording: https://youtu.be/2ExBjJ0eySo

Links shared in the meeting:

• https://eips.ethereum.org/EIPS/eip-6690
• https://ethereum-magicians.org/t/rip-7696-generic-double-scalar-multiplication-dsm-for-all-curves/19798
• https://github.com/chancehudson/moduli-comparison?tab=readme-ov-file#moduli-comparison

Summary (by kev)

• Besu & EthJS: add modular arithmetic lib
• Chance: Spec out poseidon and add a poseidon impl
• Jared: Help chance integrate into geth codebase
• Investigate whether we need to precompute poseidon constants in montgomery form
• (low priority) Investigate whether opcode inversion is so costly such that it needs to be an opcode and also used in a way that makes batch inversion not viable

[poojaranjan]

Closing in favor of #1208

[pdobacz]

I took some rough notes too, to provide overview of subjects touched. For details see recording.

• clients/implementations represented: Geth, EthJS, Besu, evmone, Cairo ZK-VM
• progress updates:
  • geth (EIP-6690 prototype+bls prototype using evmmax-bls12-381 tool)
  • evmone (low-level lib)
• Poseidon use case
  • no objections to select this as 1st priority use case to cover
    • point raised if the bottleneck for the use case isn't calldata cost rather than mod arith cost
  • what constants of Poseidon are we interested in?
    • depends on the field one's using.
  • use case of Poseidon Hash itself
    • merkle path verification, need 32 poseidon hashes for every update
    • the constants matrix is the same for all of them for a single application
    • constants change when you change the field
• choice of assembler - Huff-based like evmmax-bls12-381 vs Yul based
• how to format Montgomery constants - opaque or explicitly in Montgomery form?
  • needs measuring
• modular inversion - should this be an opcode?
  • complexity of such opcode would be large relative to current spec
  • needs measuring