Add option to output constructor bytecode by itself

[frangio]

In order to allow for proxy-style contracts where the bytecode is not redeployed but instead ran via delegatecall, the constructor needs to be somehow extracted so that it can be stored on-chain in such a way that it can be invoked for every new instance. There is currently no easy way to extract this bytecode from the Solidity compiled contract because it uses codecopy (and codesize) to obtain its arguments, and additionally it returns all of the runtime code which would not be necessary in this scenario.

This issue is to discuss possible ways in which the compiler can help this use case.

There is already an option to output the runtime code by itself (bin-runtime), so I think it would make sense to add an option to output the constructor code by itself. I'm not sure where this code would take its arguments from, though. The most convenient thing for the use case described above would be to take them from calldata. It could also simply assume that they are in memory, and in order to use it you'd have to prepend argument-loading code, but I think that presents issues with the jumps in the bytecode being absolute.

What do you think?

[chriseth]

I don't think that messing around with binaries is such a good idea, especially because it forces us to think about many different ways to use the compiler output. Would it be an option for you to modify the source code by deleting everything that is not needed at construction time and then use a delegatecall proxy in the fallback function?

[leonardoalt]

Hi @frangio , any updates on this discussion?

[eternauta1337]

@leonardoalt we are studying the situation and will get back to you soon. Thx for keeping this under your radar =)

[spalladino]

Hey folks! My apologies, I totally missed the original response by @chriseth.

Would it be an option for you to modify the source code by deleting everything that is not needed at construction time and then use a delegatecall proxy in the fallback function?

Modifying the source code is not straightforward, since we'd need a semantic analysis to know which functions are actually used by the constructor, in order to delete the others. Even if we manage to do it, we'd also need to strip the constructor code of the return statement that returns the runtime bytecode.

I think that we need some way to tap into the ContractCompiler for the constructor function (as in https://github.com/ethereum/solidity/blob/develop/libsolidity/codegen/ContractCompiler.cpp#L215), and compile the function into a contract, instead of into a ctor. However, as you say, having a compiler option for that use case may be too specific, and would end up convoluting the compiler.

We'll go back to the drawing board and see if there is a better way to handle this. Do you think it would be reasonable/possible to expand solc-js to expose more internal features of the compiler, to accommodate for this kind of use cases?

[chriseth]

solc-js is meant to be just a tiny boilerplate over standard-json. We can extend standard-json, though.

[nventuro]

In https://github.com/OpenZeppelin/openzeppelin-solidity/issues/1162, we've come accross the need to retrieve a contract's constructor bytecode from Solidity itself, as opposed to having it outputted by the compiler. https://github.com/ethereum/solidity/pull/5775 added the ability to get creation and runtime code, but the constructor by itself could be used to craft a call that initializes a new contract's storage and creates a proxy to a backing implementation contract.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 90 days. It will be automatically closed in 7 days.

[github-actions[bot]]

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.