This is the discussion topic for EIP-7873: EOF - TXCREATE and InitcodeTransaction type
There is one thing I’m missing in the EIP’s rationale - what would be the downside to having both an EOF creation transaction and InitcodeTransaction
? An obvious upside I see would be that it would remove the need to have a predeployed creation contract.
Alternatively, an InitcodeTransaction
transaction with empty to
could be special-cased to deploy the attached initcontainer, taking salt and constructor arguments from calldata, just like a predeployed contract would, but without the awkwardness of having to assign it an address and deploy it during a network upgrade.
I actually initially expected InitcodeTransation
to be a such a specialized creation transaction but after reading the EIP I see that it’s more of a generalization of the standard transaction type. It’s not even required to use TXCREATE
and deploy any of its initcontainers, which means that one could use it for arbitrary calls to EOF contracts. If the requirement to carry at least one initcontainer was relaxed it could be seen simply as an “EOF transaction” with deployment being a special case.
This is an interesting idea, the main tradeoff here would be between the complexity of predeployment (done once at fork transition), and complexity of extra feature of the transaction, that has to stay forever, and after transition is actually redundant, because the same can be achieved with non-empty-to
InitcodeTransaction after Creator Contract is deployed.
Additionaly, with such transaction it still would be required to use “Nick’s method” or similar hacks to deploy the Creator Contract in a cross-chain-safe manner, but one of the goals that EOF deployment design is trying to achieve is make such hacks unnecessary.