# PSE EVMMAX meeting notes ## 2024-11-15 (DC7SEA) PSE are building a DSL, need cryptographic primitives, on the EVM. Cannot rely on precompiles, b/c they're moving too slow. - moduli - 32 bit for now but also up to 256 bit maybe - what examples we would like to prototype, b/c EVMMAX needs a concrete program to write and benchmark and assess API - verify lattice commitment - ballpark: 6kb for proof - ballpark: need few million modulus muls - other examples and cryptographic schemes: - No concrete plans/progress on zk-fication mainnet for now - GKR (does it use pairings? A: DOn't remember, starting with lattice will be easier) - no much point in targetting ECC in EVMMAX, not future proof - EVMMAX note: as a consequence, probably no need for control flow facilities in the EVMMAX context ("ISZEROX/COMPAREX") Good 1st step to implement poseidon hash: - Solidity impl https://github.com/chancehudson/poseidon-solidity/blob/main/contracts/PoseidonT3.sol - size of the state relatively small ~30 - ~1800 instructions, 4 bytes each, but probably the unrolled version will still fit within the code size - in current EVMMAX even with static loops, you cannot use a for loop, because all args to the EVMMAX Instructions are static too - in current EVMMAXthere is no way to load constants in montgommery form, trying to avoid exposing the montgommery form, b/c abstraction - this can be revisited if good for practical reasons Vectorized EVMMAX related discussion: - vectorization worked for poseidon for _someone_. There's an article 35%? 50%? better. Using Intel AVX - EVMMAX: vectorization removes the overhead to go back to the interpreter. Needs benchmarks EVMMAX: problem with pointers in current spec (e.g. to do address target various parts of Poseidon's matrix of constants in a for loop) - boils down to efficiency - need to compete with precompiles - manipulating with offsets too much overhead - static args (immediates) can be validated in EOF deploy time - tradeoffs Next steps: - translate poseidon to EVMMAX - benchmark against regular EVM - (implement euclidean inversion in EVMMAX) - "YulMAX" - nominated Yul as assembler of choice, even if imperfect