This EIP extends the definition of types_section in EOF format (EIP-3540) with an additional type parameter.
An additional type parameter allows the EOF EVM interpreter to identify the "type" of a code section. This allows the interpreter to "interpret" each code section differently, allowing EOF function calls to, for example, invoke pure EVM64 code or even later support RISC-V.
types_section, as defined in EIP-3540, is changed to be of the following format (type, reserved, inputs, outputs, max_stack_increase). type is uint8, reserved is 24 bits, and inputs, outputs, max_stack_increase are defined as uint8, uint8, uint16 respectively, the same as before. The only valid type defined in this EIP is 0x01. Additional EIPs may be defined for other code section types.
version, as defined in EIP-3540, is changed to 0x02, to avoid the backward compatibility issue if a third-party chain already deployed EOF in production.
In EOF container, the following validation rules are added:
type in types_section is not of an known type, then the validation fails.reserved in types_section must be all zeros.The new type parameter allows a contract to "dispatch" to different variants of the interpreter to better suit its need.
Allowing this type to be defined for each code section ensures that a contract remains conscise -- it can quickly switch between its computational needs and system/runtime needs.
reserved is added to types_section to maintain the proper padding. Each item in types_section is now 64 bits in total.
As we know, EOF, including EIP-3540, was extremely close to being deployed before it was decided to withdraw from Fusaka. To avoid the issue that some third-party chains have already deployed EOF in production (given the state of EOF we can consider this to be likely), we bump version of EOF to 0x02. 0x01 is now invalid.
No other backward compatibility issues found.
To be added.
To be added.
Needs discussion.
Copyright and related rights waived via CC0.