Provide access to a contract's creation and runtime code

[chriseth]

Contract types should get new members:

• creationCode
• runtimeCode

which are immutable members of bytes memory type that provide access to the contract's creation and runtime code. This is useful for using create2 in inline assembly.

If the optimizer does not compute keccak256(C.creationCode), we should also provide an accessor for that.

Note that we have to be careful with libraries, because they modifier their code at creation time.

[chriseth]

@axic noted that it should not be breaking and I think I agree :)

[jochem-brouwer]

This is dangerous!

Example:

contract Test{

function a() public view returns (uint) { return 3; }

    constructor() public { 
        assembly{ 

            return(0,0)
        }
    }
}

This does not dump any code at an address while solidity assumes that the function a() can be reached. Hence runtime code is empty, but solidity thinks runtime code is not empty.

[chriseth]

I agree that this needs to be properly documented, but I would argue that the runtime code of the contract type Test is still well-defined and non-empty. Using C.runtimeCode has the same pitfalls as calling a on a contract of type C has. The danger does not lie in C.runtimeCode, it lies in not properly understanding the code of a contract that uses inline assembly.

[axic]

@chriseth mentioned contract types already have structs and enums as properties and runtimeCode/creationCode would conflict with that.

A potential solutions is to consider #1447: meta(C).runtimeCode.

meta is not a keyword currently and this would mean making this a breaking change. @chriseth suggested to use type(C), I've suggested to use contract(C) as an alternative solution.

[ekpyron]

At the moment I'd actually prefer type over meta and contract...

[ekpyron]

Although I'd make it a method then type(C).creationCode().

[chriseth]

Implementing as type(C).creationCode and type(C).runtimeCode. The same restrictions about cyclicity apply as for the new operator (cannot access the code of the current contract, etc).

[axic]

The same restrictions about cyclicity apply as for the new operator (cannot access the code of the current contract, etc).

That shouldn't be problem if it uses codecopy.

[chriseth]

@axic I'm going with the same semantics for new for now for ease of implementation. If people request this, we can relax it. For now, I have only seen factory contracts and not contracts that can clone themselves.

[chriseth]

It turns out the optimizer cannot optimize keccak256(type(C).creationCode). Furthermore, it might also be difficult to provide direct access to it, because the hash will only be fixed after assembly.

[axic]

Right, perhaps if we assume the main user going to be factory contracts, then for the single reason of being able to optimise out the has it makes sense to make that restriction right now.

[chriseth]

Why did we call this runtimeCode and not deployedCode? :(