Support for CodeSection type for linking externally written/compiled bytecode with EOF supported Solidity contracts. #15211
Labels
closed due inactivity
The issue/PR was automatically closed due to inactivity.
feature
stale
The issue/PR was marked as stale because it has been open for too long.
Abstract
Currently in solidity, there's no native support for linking an externally compiled bytecode with a solidity contract and being able to call into it. Walkarounds for this have been made e.g dynamic huffidity which utilizes function pointers and manually returning bytecode from the constructor to achieve this but for obvious reasons have not been used in production (that i know of). Implementing native support for this feature, particularly with EOF (EVM Object Format) likely to come in Prague, could resolve these issues cleanly.
A scenario where this could have been helpful is with Tornado Cash. It uses a handwritten bytecode MiMCSponge implementation to be as optimal as possible but because it couldn't be linked with the solidity contract it had to be deployed as a separate contract that's called externally.
Motivation
I propose a
CodeSection
type, defined as a struct of 4 fields, each of which are relevant to create a valid TypeSection for the given container and for compile-time validation.This is to be defined at the contract/file level and must be known at compile time so that it can be validated and linked together with the solidity code.
When used in inline assembly, a variable of type CodeSection is actually a uint256 constant that holds the code section index of the bytecode (similar to how functions types hold its implementation PC) and not the struct field's values. These values are only for compilation and become part of the bytecode afterwards.
Specification
Within any function, the code section can be called via solidity or inline assembly and outputs are to be completely consumed or acknowledged to exist at least.
Example with a code section that takes in 2 inputs and returns 2 outputs (
a / b
,a % b
):Under the hood, this would simply
CALLF
intohuffCode
's code section and execute it, thenhuffCode
returns execution back to the calling code section with the given outputs pushed to its stack to continue execution.Note: Since memory is shared between code sections, similar to inline assembly the concept of memory safe code sections would also be a thing i.e you can mark the code section call as memory safe i.e the bytecode maintains the memory allocation rules of solidity.
Backwards Compatibility
No backwards compatibility issues I can think of currently.
The text was updated successfully, but these errors were encountered: