VIP: add function to create clones with immutable args

[banteg]

Simple Summary

Add a new built-in function to create Clones With Immutable Args.

Motivation

Vyper maintains a strong stance against upgradeable contracts. It offers safe immutable contract creation patterns to developers, promoting the use of minimal proxies and blueprints.

This pattern offers a middle ground between them, and makes the most sense when the expected usage of the contract is short-lived or the deploy cost is prioritized over runtime cost.

It cheapens runtime cost compared to EIP-1167 because it allows the proxy to have an immutable data section, which gets forwarded to the logic contract as appended calldata, where it can be read from msg.data by the logic contract.

This pattern has seen production use by Ajna, Astaria, Sudoswap, Buttonwood.

Specification

Add a built in function

def create_clone_with_immutable_args(
    target: address,
    immutables: Bytes[65533],
    value: uint256 = 0,
    salt: bytes32 = None,
)

Similarly to EIP-1167 proxies, it constructs an init code based on the arguments and deploys a new contract using CREATE or CREATE2 opcode, depending on whether salt was set.

An annotated init code can be found here.

The data section can't exceed 65,533 bytes, since the data length is encoded as uint16 and it includes the length of marker itself.

It is left up to the factory and the logic contract to know how to encode and read variables from the immutable section.

Backwards Compatibility

This VIP adds new functionality and doesn't break backwards compatibility.

Dependencies

This VIP doesn't have any external dependencies.

References

• Solidity Reference Implementation
• Huff Implementation
• Solidity Factory Example
• Solidity Clone Example
• Vyper Clone Example

Copyright

Copyright and related rights waived via CC0

[charles-cooper]

i think an important point to clarify here is that in terms of motivation, the desired use case is to deploy short-lived CWIAs where the deploy cost can be expensive relative to expected usage, whereas with the existing blueprint pattern, the deployed contract is expected to "live forever" and so the deploy cost does not matter much

[banteg]

an alternative syntax instead of immutables buffer could be *args that would be abi encoded. it would also make sense to generate some metadata with their offsets.