# Edelweiss EVMMAX Breakout ## Background - EIP (`SETMODX` instruction to change configuration at runtime): https://github.com/ethereum/EIPs/pull/5843 - Modified version using EOF to have static configuration: https://notes.ethereum.org/@ipsilon/BJICGFRoo ## Discussion - The method in the EIP requires a number of checks to be done at runtime (memory offsets/expansion), but is flexible. - Static configuration enables moving all checks but one (value fits modulus) to deploy time validation - With static config can roll out evmmax with allowing a few known moduli first - Static config doesn't allow mixing different moduli in the same execution - Problem with RSA, would require "infinite" number of contracts to be deployed - PLONK(2?) verifier interleaves two moduli - Observing values in montgomery form is not desired - Setup instruction could consider having a "context id", to have multiple contexts at the same time. With opaque memory these would be independent. - Could have a max limit in the header. - Having `bit_width` and maximum slot count in the header is desired (to preallocate and validate offsets) - If header only includes `bit_width`, can we preset the context with default values (i.e. 0 or ~0 for modulus?) - This removes the need to check "is_context_valid" at runtime. ## Decisions & Next steps 1. Want runtime changeable configuration. - Support RSA - Support replacing the modexp precompile - Support PLONK(2?) 2. Want to make montgomery values opaque. - Implies the need of load/store instructions (copying between regular memory and evmmax memory). 3. Should keep configuration header for width and limits. 4. Main obstacle would be cost (is it several x slower than the corresponding precompile?) 5. Target use cases: - bls12, mimc, poseidon, rsa, modexp precompile - secp256/bn256 could be also implemented, but they exists as (seemingly) well tested precompiles 6. Present a new spec according to the above in the coming month.