The two spec change topics represent potential additions to EOF, once utility and security are established.
Allowing to:nil in Initcode Transacitons
This is the remaining question from meeting 71’s discussion on bootstrapping EOF contracts: should we allow ‘to:nil’ handling as seen in Frontier series transactions.
The previous bootsrapping pre-read listed sis options. Two prior bootstrap options are withdrawn in eof-devnet-1: (a) the predeploy contract due to technical details and ACD process concerns with the removeal of EIP-7666 from Fusaka scope and (b) EIP-7698 overloading of Frontier, access list, and fee market transactions.
The plan of record is to expose TXCREATE as an opcode outside the EOF container and allow non-container code to thus deploy EOF contracts into account code storage. This reflects what the initial batch of eof-devnet-1 tests uses.
Whether there are going to be “standard” TXCREATE contracts is an ERC question, as they ERC contracts can be deployed via existing toehold contracts enumerated in RIP-7640 (Deterministic Deployment Proxy, Safe Singleton Factory, CreateX, and the Create2 Deployer) and keep the same address in chains that support RIP-7640.
A lot of the discussion time was spent on address derivation for the options where to:nil is allowed in InitcodeTransacitons. The tension was between two issues relating to adding the sender address to the address derivation: safety and cross-chain utility. If the address is not added then a contract creation tx can be front run. However, if the contract does not rely on the creating address nor on other variable or side effects that could be changed (such as available ether) then the front-running is idempotent. This ability to be moved between callers is also how it gains the ability to be cross-chain safe, as long as the chain-id and sender address is not in the derivation then those can be changed in a transaction and it can be re-signed by another EOA on another chain.
Options to consider are
Status Quo: no to:nil in Initcode Transactions
Accepting the Security risk
Providing configurability to optionally add sender restriction to the call (either via calldata encoding or anoter transaciton type)
Adding EOF opcodes outside the EOF container
Another possible addition is to expose opcodes introduced for the benefit of EOF outside of the container. This is particularly relevant for the PAY opcode. The facilitator in meeting 71 asked for those who would use these opcodes outside of an EOF container to comment in the relevant eth-magicians threads. Those are:
Opcodes with immediate arguments (such s RJUMP) and opcodes referring to the container itself (such as DATALOAD) are not good candidates for exposing outside the container.