-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EOF Devnets Breakout Room #653
Comments
Great, thanks, @timbeiko! CC @diega, @meowsbits, @ziogaschr. |
EOF OneShot™ specifications:
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:
Earlier attempts at EVM versioning, static jumps and subroutines:
|
Suggested formatting tweak for 4200 and 3540 titles: |
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. |
Thanks. Updated in #653 (comment), @axic. |
I'd do the first iteration with the ones already implemented for Shanghai:
and also include:
This should stabilize what has been already implemented (including state tests). In the second stage we should include:
For later we have:
|
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. |
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. |
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. |
And a minor "marketing" suggestion:
|
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". |
For me, the most important thing is that what the Ipsilon team is proposing is a Validated EVM. Good things will come of that. |
@AlexeyAkhunov Is anybody from Erigon planning to attend? Best wishes! |
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. |
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. |
Meeting Info
📆 Subscribe to the Ethereum Protocol Call calendar for calendar invites
Agenda
The text was updated successfully, but these errors were encountered: