Currently, Ethereum bytecode has no syntactic structure, and subroutines have no defined interfaces.
We propose to add procedures – delimited blocks of code that can be entered only by calling into them via defined interfaces.
Also, the EVM currently has no automatic management of memory for procedures. So we also propose to automatically reserve call frames on an in-memory stack.
Constraints on the use of procedures must be validated at contract initialization time to maintain the safety properties of EIP-3779: Valid programs will not halt with an exception unless they run out of gas or recursively overflow stack.
What is the motivation to have multiple sections with multiple entry points in each one as opposed to
- multiple sections each one with a single entry point
- or a single code section with multiple entry points?
The motivation is just to allow for the encapsulation of related sets of procedures into independent code sections. External tools could then combine these sections like libraries for different contracts.
The encapsulation allows for all of the procedures in a section to share optimized subroutines that will not be accessible to other code sections. (And if we don’t allow for multiple entry points we can wind up with people using flags to do the job with a single one anyway.)
How will they be not accessible? Isn’t
CALLPROC allowing to call any entry point of any section?
Subroutines are accessed via RJUMPSUB, which is always limited to the current code section. And only those procedures called out in an Entry Point section can be called from a different code section.
I’ll note that the procedure concept stands on its own, and I could propose these opcodes independently if we don’t find them useful as entry points.
I’ve taken my own suggestion, @gumb0 and narrowed this EIP down to just specifying procedures.