Glamsterdam headliner proposal: EVM64

EIPs
1

This is a headliner proposal for EVM64 for Glamsterdam.

Summary

Headliner proposal for EVM64.

Option A is EVM64 with prefix opcode 0xC0.

  • EIP-7937 of EVM64 for endianness-independent arithmetic, comparison, bitwise and flow operations.
  • EIP-9819 for EOF support.
  • EIP-9821 for little-endian BYTE64, MLOAD64, MSTORE64 and PUSH*64 opcodes.

Option B is “pure” EVM64 via EOF code section.

  • EIP-9834 which defines an extended version of types_section for EOF.
  • EIP-9835 which defines the EVM64 code section type.

Detailed justification

The benefit of this proposal includes:

  • Improve throughput and reduce gas costs for writing computationally intensive algorithms in EVM. Many algorithms cannot utilize the full 256-bit.
  • Make EVM JITs / AOTs, as well as EVM-to-RISCV recompilers in the future, more attractive. At this moment, any EVM contract re-compile will be roughly 4x the size (because 1 256-bit op will be at least 4 64-bit ops), which is a considerable bottleneck.

Why consider the inclusion now:

  • There are an increasing amount of EVM contracts on-chain that are computationally intensive nowadays, especially for rollups. Many of them wait for certain precompiles on-chain. But precompiles can’t foresee all possible use cases. EVM64 provide with them a possible alternative path that does not depend on Ethereum network upgrades.
  • With the beginning of the recent discussions of potential RISC-V contracts on Ethereum, EVM64 prepares us for the future when we eventually need EVM-to-RISCV recompilation.

Stakeholder impact

  • Positive: An important tool for smart contract developers for computationally intensive contracts.
  • Negative: Implementation complexity for core devs.

Technical readiness

The core EIP (EIP-7937) is specification-ready. Benchmarks are being worked on. A reference implementation is available in rust-evm.

Security & open questions

The core EIP (EIP-7937) has no known open questions.

The design of the optional additional EIP with regards to BYTE64, MLOAD64, MSTORE64, PUSH*64 is ready, but additional discussions about endianness is still open.

For past discussions and reviews about EIP-7937 please also see the Github PR.

1 Like
2

I love the idea, not sure if I love the whole implementation/specification, especially with the prefix opcode.

I wonder if we could combine this with EOF in that way that some functions would be in 64bit context while other in 256bit, we could then reuse opcodes and only pay slightly when crossing the boundry.

3

I personally think multibyte opcode would be inevitable. We only ever have 256 single byte opcodes and it’s probably important to save it.

Having prefix opcode is not uncommon in other architectures, and I think this will open a lot of additional doors for us. For example, we can have another prefix opcode that changes the behavior of arithmetic operations from overflowing to checked OOG, eliminating the common need for SafeMath.

Yep this is possible. We can build on top of EIP-4750 and define a new section type. Once entered, the full section will run EVM64/LE only (with the stack being 64-bit only).

But this one will have the drawback that almost all other (system/runtime) opcodes must be disabled (because they need 256 bit stack). We can’t have interop if we don’t use prefix opcode design, because otherwise the arithmetic operations can’t ever operate on the most significant 192 bits.

Anyway, I’ll write an EIP for this as well for us to have choices. You’ll see the pros and cons to be really obvious. Personally I really lean towards the current prefix opcode design, because the alternative will make interop difficult, and significantly hinders gradual optimization.

4

Please see EIP-9834 and EIP-9835. This actually turned out to be a little bit better than I thought.

Pros:

  • “Pure” EVM64.
  • No more code size increase.

Cons:

  • “Pure” computation only. No system/runtime calls. But this may not be that of a big problem because memory is shared.
  • Can’t do gradual optimization – a function is either purely EVM64 or it is not.