# EIP Draft: Replace alt_bn128 Precompiles With EVM Bytecode --- eip: TBD title: Replace alt_bn128 Precompiles With EVM Bytecode authors: Paul D. (@poemm) discussions-to: TBD type: Standards Track category: Core status: Draft created: TBD --- ## Simple Summary We propose replacing the alt_bn128 precompiles with EVM bytecode. ## Abstract alt_bn128 precompiles has low cryptographic security, much lower than the desired 128-bits. And alt_bn128 precompiles may soon be obsolete as new precompiles are accepted. We propose a path to deprecation which replaces precompiles with formally verified functionally equivalent EVM bytecode, and replaces precompile gas formulas with regular EVM gas accounting. ## Motivation We are motivated to remove obsolete code from Ethereum clients. Obsolete code leaves a large attack surface, but provides little value. We are also motivated to "lower the bar" for implementing a new Ethereum client, improving client diversity. ## Specification Starting at block `TBD`, precompiles at addresses 0x00..006, 0x00..007, and 0x00..008 will execute functionally equivalent (i.e. formally verified) EVM bytecode. Gas accounting is switched from formulas to the standard EVM opcode gas accounting. The bytecode for pairings will not fit in 24kb, so we will also deploy and call helper contracts with TBD addresses. ## Rationale Elliptic curve precompiles add a significant amount of code, some say 15,000 lines of likely bug-ridden code. With BLS12-381 precompiles, BN128 precompiles become functionally obsolete, but remain a large attack surface in Ethereum clients. It would be good to "trade" attack surface by removing BN128 precompile code when adding BLS12-381 code. The bytecode will be formally verified to be functionally equivalent to a high-level mathematical specification. [Weierstrudel](https://github.com/AztecProtocol/weierstrudel) showed us that we can implement fast ECMUL in pure EVM. Likewise, ECADD (a part of ECMUL) can also be implemented in pure EVM. Finally, ECPAIRING has potential to be implemented in EVM384, which is fast in both [runtime](https://notes.ethereum.org/@poemm/evm384-update4) and [gas](https://notes.ethereum.org/@poemm/evm384-update5). ## Backwards Compatibility Dapps which observe gas of precompiles may break. But there was never any promise of fixed gas costs. In fact, gas costs for precompiles frequently change. ## Test Cases TBD (same as the precompile) ## Reference Implementation The reference implementation will be formally verified EVM bytecode. ## Security Considerations TBD ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
Last changed by  
 
Paul D.
592

Read more

EIP Draft: EVM384 and Friends

THIS DRAFT IS STILL BEING UPDATED. eip: TBD title: EVM384 and Friends (Modular Arithmetic Extensions) authors: TBD discussions-to: https://ethereum-magicians.org/t/evm384-feedback-and-discussion/4533 type: Standards Track category: Core status: Draft created: TBD

5/15/2021
EVM384 Specs

[toc] Specs as Addenda to Yellowpaper Appendix H We use notation from the yellowpaper. value Mnemonic delta alpha Description

3/19/2021
EVM384 Update 5: First Gas Cost Estimates

Text jointly authored by (in alphabetic order by last name) Alex Beregszaszi, Pawel Bylica, Casey Detrio, Paul Dworzanski, and Jared Wasinger with help from the entire Ewasm team. [TOC] Introduction This is a continuation of a series of updates on EVM384. Preview of EVM384 Update 1: Can we do fast crypto in EVM? Update 2: The Interfaces

1/22/2021
EVM384 Security Analysis: Potential Gas DoS Attacks

This is a living document to analyze potential runtime amplification attacks on EVM384 opcode gas costs. It remains an open question whether attacks are possible. Recall that EVM384 proposes three new opcodes, ADDMOD384, SUBMOD384, and MULMODMONT384. Each EVM384 opcode pops one stack item from which it reads four packed memory offsets, each 32-bits. The offsets are to (i) two input 48-byte values, (ii) one input 48-byte modulus and, for MULMODMONT384, a 8-byte parameter concatenated, and (iii) an output of 48-bytes. For more information, the most comprehensive list of EVM384 links is in this magicians thread. Comparing EVM384 to EVM, the closest opcodes in terms of memory use are MLOAD, MSTORE, SHA3, and *COPY. But these each access one memory offset, and a possibly long sequential array. There are no opcodes which access four memory offsets like EVM384 opcodes do. Perhaps an attack can exploit this many memory accesses. If all accesses are cache misses, then execution may be slow. Moreover, the bytecode itself can be a cache miss, resulting in a slowdown to read the next opcode. This can be further amplified if each cache miss was also a TLB miss, which results in an expensive page walk to resolve the virtual -> physical address mapping. In this security analysis, CPUs of interest have L1 cache of at least 64KB, possibly more cache layers until a final cache layer of at least 4MB, and a memory of at least 1GB. We assume that cache lines are 64 bytes, which is common.

1/22/2021
Read more from Paul D.
Published on HackMD