The create address derivation for EOFCREATE is based on CREATE2.
keccack256(sender_address + salt + keccak256(init-container))
where the sender_address is the logical address of the contract invoking EOFCREATE.
We identified that the keccak256(init-container) goes against the "code non-observability" because it locks in the contents of the init-container e.g. preventing re-writing it in some future upgrade.
It also seems unnecessary expensive: EOFCREATE can only pick up one of the deploy-time sub-containers.
Solution 1: Use sub-container index
The create address is already bound to the "sender address", code is immutable (no SELFDESTRUCT) so replacing the hash of the sub-container with just its index may be enough.
Solution 2: Use code's address + sub-container index
The CREATE2 scheme uses the "sender address" with may not be the address of the code (see DELEGATECALL). I'm not sure if this is desired property for CREATE2. But for EOFCREATE this looks to be a problem. A contract may deploy different contract using DELEGATECALL proxy: for EOFCREATE inside a DELEGATECALL the same sub-container index will point to different sub-container. To fix this we can replace/combine the physical code address:
keccak256(code_address + salt + sub-container-index)
keccak256(sender_address + code_address + salt + sub-container-index)
The create address derivation for
EOFCREATEis based onCREATE2.where the
sender_addressis the logical address of the contract invokingEOFCREATE.We identified that the
keccak256(init-container)goes against the "code non-observability" because it locks in the contents of the init-container e.g. preventing re-writing it in some future upgrade.It also seems unnecessary expensive:
EOFCREATEcan only pick up one of the deploy-time sub-containers.Solution 1: Use sub-container index
The create address is already bound to the "sender address", code is immutable (no
SELFDESTRUCT) so replacing the hash of the sub-container with just its index may be enough.Solution 2: Use code's address + sub-container index
The
CREATE2scheme uses the "sender address" with may not be the address of the code (seeDELEGATECALL). I'm not sure if this is desired property forCREATE2. But forEOFCREATEthis looks to be a problem. A contract may deploy different contract usingDELEGATECALLproxy: forEOFCREATEinside aDELEGATECALLthe same sub-container index will point to different sub-container. To fix this we can replace/combine the physical code address:keccak256(code_address + salt + sub-container-index)keccak256(sender_address + code_address + salt + sub-container-index)