Closed AmadiMichael closed 1 day ago
An added benefit of this is calling solidity/assembly functions from an inline assembly block via CALLF
.
Currently in solidity its not possible to call your contracts' solidity function while in an assembly block or an assembly block's function from another assembly block within the same function. It would be a helpful feature if a shared function can be set to have a distinct code section and hence can be callable from any inline assembly block within that contract.
This issue has been marked as stale due to inactivity for the last 90 days. It will be automatically closed in 7 days.
Hi everyone! This issue has been automatically closed due to inactivity. If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen. However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.
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.