Add EIP: EVM Modular Arithmetic Extensions (EVMMAX)

[jwasinger]

EthMagicians discussion thread here.

[eth-bot]

✅ All reviewers have approved.

[Pandapip1]

Fix the walidator issues, and only add one file.

Where did you get EIP-6601 from?

[odysseus0]

Yo @jwasinger , we are a group of wallet builders building on top of account abstraction and super excited about the EIPs you have been working on to add more elliptic curve support. Any chance we can know more about the current progress and how we can help? This is an extremely important feature to us.

[jwasinger]

Hey @odysseus0 , I've been mostly afk for a couple of weeks and just getting back now.

It seems likely that EOF will be included in a subsequent hardfork, so the proposal that ends up being pushed forward will probably be similar to EIP 6601.

6601 + EOF offer several benefits compared to 6690:

• removal of dynamic jumps allows ADDMODX/SUBMODX/MULMODX to be implemented without potentially breaking existing contracts.
• the amount of EVMMAX memory that can be used by a contract is known at deploy time.
• several values that must be precomputed per a given modulus are computed once at deploy time and embedded in the deployed contract inside a new EOF section: this will give slight gas savings compared to 6690.

EIP-6601 is not implemented currently as the EOF dependencies are not fully implemented in Geth yet.

Right now, I have a proof-of-concept implementation of a template system for writing Huff contracts using EIP-6690: https://github.com/jwasinger/evmmax-bls12-381 .

As the name implies, the repo contains implementations of BLS12-381 operations (right now ecmul and ecadd for G1/G2). The Geth submodule in that repo links to a partial implementation of 6690 (right now only supports moduli 321-384 bits, does not implement gas charging for SETMODX/LOADX/STOREX operations or the modified EVM memory expansion function).

From the perspective of a developer using my templating system: whether 6601, 6690 (or some similar variant) goes live, the details are (and will be) mostly abstracted by the templating engine. This means that most EC code written now using EIP-6690 should require minimal modifications to be adapted for the final proposal.

So if there is interest now in implementing additional curves (or bls operations), I can improve and document the template system and associated Geth implementation to make the development process easier.

Regardless, I think a good first step would be to collect more desired use-cases (curves, zk-friendly hash functions, zkp schemes, etc.) and analyze them. So I would be curious from to hear from the AA side: what additional curves (and curve operations) would be most important to you for unlocking new use-cases?

[drortirosh]

what additional curves (and curve operations) would be most important to you for unlocking new use-cases?

The most important curve is sec256r1.
This curve is standardized and supported by secure enclaves on various devices (iPhones, Android, macos) and have standard a opis on those devices, as on common browsers.

Existing evm code to verify the signature is roughly 600k gas, which is too expensive for general use.
It would be desirable to have it cost roughly as
Sec256k1 (evrecover), and then it could become a few facto standard signature.

[jwasinger]

I forgot to post a link to the EthMagicians discussion thread where this discussion should happen. I've posted a response there.

[Ivshti]

I second @drortirosh - sec256r1 unlocks support for Secure Enclaves that are already built into iPhones, as well as WebAuthn and Apple Passkeys.

Other curves I’d like to see

• gmail DKIM signing uses ed25519 - this would enable smart accounts to be recovered via your email address
• estonian digital IDs use Secp384r1

eipw passing

[eth-bot]

All Reviewers Have Approved; Performing Automatic Merge...

[eth-bot]

All Reviewers Have Approved; Performing Automatic Merge...

[github-actions]

The commit 42ffb90 (as a parent of 87991ed) contains errors.
Please inspect the Run Summary for details.