EOF Devnets Breakout Room

[timbeiko]

Meeting Info

• Nov 4, 2022, 14:00 UTC
• Duration: 60 minutes
• Recording: https://youtu.be/3Nx0z0-bhsU
• Notes: https://notes.ethereum.org/@timbeiko/eof-breakout

📆 Subscribe to the Ethereum Protocol Call calendar for calendar invites

Agenda

• EOF "feature complete" EIPs list
  • EIP-3540
  • EIP-3670
  • EIP-4200
  • EIP-4750
  • Anything else?
• EOF devnet 1
  • Target EIPs
  • Client Implementations
  • Testing

[bobsummerwill]

Great, thanks, @timbeiko!

CC @diega, @meowsbits, @ziogaschr.

[bobsummerwill]

EOF OneShot™ specifications:

• EIP-3540 - EVM Object Format (EOF) v1
• EIP-3670 - EOF - Code Validation
• EIP-4200 - Static relative jumps
• EIP-4750 - EOF - Functions
• EIP-5450 - EOF - Stack Validation

A way to remove jumpdest analysis if we want to keep dynamic jumps, but in a EIP-4200+EIP-4750 world it would not be implemented:

• EIP-3690 - EOF - JUMPDEST Table

Earlier attempts at EVM versioning, static jumps and subroutines:

• EIP-615 - Subroutines and Static Jumps for the EVM
• EIP-1702 - Generalized Account Versioning Scheme
• EIP-2315 - Simple Subroutines for the EVM

[bobsummerwill]

Suggested formatting tweak for 4200 and 3540 titles:
ethereum/EIPs#5849

CC @axic, @gumb0, @chfast

[axic]

The last piece is EIP-5450: EOF - Stack Validation removes the need for stack underflow checks and most cases of overflow checks.

EIP-3690 would be a way to remove jumpdest analysis if we want to keep dynamic jumps, but in a EIP-4200+EIP-4750 world it would not be implemented.

[bobsummerwill]

Thanks. Updated in #653 (comment), @axic.

[chfast]

I'd do the first iteration with the ones already implemented for Shanghai:

• EIP-3540 - EVM Object Format (EOF) v1
• EIP-3670 - EOF - Code Validation

and also include:

• EIP-3855 - PUSH0 instruction (EVM related and very easy to add)
• EIP-3860 - Limit and meter initcode (Important because this covers the EOF validation cost)

This should stabilize what has been already implemented (including state tests).

In the second stage we should include:

• EIP-4200 - Static relative jumps
• EIP-4750 - EOF - Functions

For later we have:

• EIP-5450 - EOF - Stack Validation
• and some other ideas (just some examples, let's keep the discussion for some other place and time):
  • unlimited DUP and SWAP
  • instruction cleanups (e.g. get rid of output arguments for calls)
  • gas observability
  • NOP instruction
  • gas cost reduction

[gcolvin]

The trouble with doing things in stages is that it would take years. Until Stack Validation is in we will not have even have the functional equivalent of EIP-615, which is the least we need to allow us to compile EVM code to machine code in linear time and space.

[shemnon]

The concern I have with stack validation is there is basically no specification in the EIP as to what "the instruction flow traversal procedure, where every possible code path is examined, and data stack height at each instruction is recorded" is apart from the reference implementation in python. And then that reference implementation I read as O(n^2), not good for critical path code and a target for attacks.

For comparison the JVM has an entire section on code validation (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.10), but they are adding in type validation at each stack entry. section 4.10.2.2 is more about what I expect the specification would be.

[gcolvin]

The algorithm can be and should be linear in time and space. (The Wasm algorithm is.) If it's not it needs fixing.

EIP-615 provided essentiality the same safety guarantees as the full EOF suite, stated as both a set of constraints on valid code and an algorithm to validate those constraints. EIP-2315 also takes this approach for a weaker set of guarantees. So validity can be stated as a set of constraints independently of the algorithm that enforces those constraints.

(The Wasm spec is entirely declarative. The validation algorithm is a non-normative appendix.)

For EIP-5450 you have to go through all of the EIPs it requires to find all of the constraints and their corresponding validation algorithms. Most of the constraints are expressed as exceptional halts during instruction execution which validation seeks to prevent. It might be helpful to restate all of the constraints in EIP-5450 and to give a single, unified validation algorithm.

And yeah, we only have one data type, so only the number of items on the stack matters. If that ever changes we will need to expand our EOF tables to include JVM-style stack maps and expand the validation algorithm accordingly.

EDIT: I should have noted that EIP-5450, for itself, clearly defines and constrains the 6 properties of valid code that it verifies. It does this independently of the reference implementation.

[gcolvin]

And a minor "marketing" suggestion:

EVM2 = EOF(eip-3540, eip-3670, eip-4200, eip-4750, eip-5450)

[shemnon]

EOF version 1 is EVM 2? Not as bad as ProgEVM, but not great. There's also confusion with the EVMOne project, would EVMTwo be the successor?

If it needs differentiation (and I'm not sure that would help marketing wise) I would want something like EEVM for "Encapsulated EVM".

[gcolvin]

For me, the most important thing is that what the Ipsilon team is proposing is a Validated EVM. Good things will come of that.

[bobsummerwill]

@AlexeyAkhunov Is anybody from Erigon planning to attend? Best wishes!

[holgerd77]

Just reading up on the call notes here, so we are working on withdrawals right now and will be ready with this in 1-2 weeks, if wished we can happily reboot the Shandong testnet in a v2 version without the EOF stuff and then additionally including withdrawals.

[gumb0]

The concern I have with stack validation is there is basically no specification in the EIP as to what "the instruction flow traversal procedure, where every possible code path is examined, and data stack height at each instruction is recorded" is apart from the reference implementation in python. And then that reference implementation I read as O(n^2), not good for critical path code and a target for attacks.

For comparison the JVM has an entire section on code validation (https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.10), but they are adding in type validation at each stack entry. section 4.10.2.2 is more about what I expect the specification would be.

We don't claim python reference implementation is the most efficient, but it is linear in number of instructions, as each instruction is examined once and python dict lookup (which is O(1)) is done for each one. It's basically CFG traversal in breadth-first-search manner (where the only branches are RJUMPI).

Thank you for the pointer to Java validation spec, it will help us to try to better describe the algorithm verbally.