You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just stumbled upon a nice summary from gcolvin on upcoming planned/discussed EVM changes (all in the form of new EIPs): ethereum/pm#450 (comment)
Will re-cite here:
It's not necessary to do them all in one fork, @holiman , depending on how crowded the forks get and how long between forks.
There was talk last year of having one fork devoted to the various EVM improvements which have been six years in the making, and all-in-all form a complete, safe and efficient control-flow facility. They make for a big meal, but no bigger than EIP-615 was. A reasonable order of inclusion would be as follows.
These are essential for most of the remainder.
EIP-3540: EVM Object Format (EOF)
EIP-3670: EOF - Code Validation
EIP-3860: Limit and meter initcode
These provide static jumps and subroutines. They are compatible but not interdependent.
EIP-4200: Static relative jumps
EIP-2315: Simple Subroutines for the EVM
This specifies additional validation to constrain JUMP, JUMPI , static jumps and subroutines -- thus providing a higher level of safety than promised by EIP-615. It depends on the object format, validation, static jumps, and subroutines.
EIP-3779: Safer Control Flow for the EVM
This is in early design stage. It provides multiple code sections, procedures with defined interfaces, and a frame stack for disciplined use of memory.
EIP-4573: Entry Points and Procedures for EVM Code Sections
And these are independent of the others, and can be included independently.
EIP-3855: PUSH0 instruction
EIP-1153: Transient storage opcodes
No imminently pressing, but one thing very much certain to be integrated into the next feature HF (Shanghai) and at the same time pretty complex is the proposed EVM Object Format. The associated EIP-3540 is pretty extensive and we should at some point start to deal with the changes and start to implement.
This is a very high-level structural update introducing a new container format for EVM bytecode to allow for easier VM feature updates in the future.
The text was updated successfully, but these errors were encountered:
Outdated, we should rather follow on the remaining not-yet-implemented EIPs here on a per-EIP basis and follow along with Shanghai discussions on inclusion.
Just stumbled upon a nice summary from gcolvin on upcoming planned/discussed EVM changes (all in the form of new EIPs): ethereum/pm#450 (comment)
Will re-cite here:
No imminently pressing, but one thing very much certain to be integrated into the next feature HF (Shanghai) and at the same time pretty complex is the proposed EVM Object Format. The associated EIP-3540 is pretty extensive and we should at some point start to deal with the changes and start to implement.
This is a very high-level structural update introducing a new container format for EVM bytecode to allow for easier VM feature updates in the future.
The text was updated successfully, but these errors were encountered: