Was just thinking about this today.
One thing that could really help as an intermediate step is simply letting a transaction execute multiple calls. Could this be as simple as letting to and data in a transaction be lists, or finding some other way of organizing it so 1 transaction can execute 2+ calls?
EIP-2711 would enable batch transactions, which would guarantee order (though not atomicity). So you could submit a single transaction, with a single signature, that did an erc20.approve followed by a erc20.transfer.
That’s doable, but personally I think this approach is simpler, since it reuses existing mechanisms in the EVM rather than introducing new ones.
Hi, we can generalize this EIP to extend CREATE functionality. Because it already executes calldata as EVM bytecode but then charge 32k gas for contract creation + 200 gas for every byte. Let’s disable charging 32k of gas for the cases when returned smart contract size is 0.
The big difference with this proposal vs just doing a CREATE is that this proposal effectively makes it so you can delegatecall the first call frame. If you do a CREATE and then in the “constructor” you call some external function, the CALLER of that function will be the contract address, not the person who signed the transaction. This EIP would make it so the CALLER would be the transaction signer instead.
@MicahZoltu thx for the clarification. I was thinking about InfiniteApprove smart contract working with user signatures to forget about approve transactions and use signatures even for tokens do not support permit().
One of the most dangerous things in this EIP, that some malicious Dapp could make tx spending all your assets.
At the moment, end-users are always at risk when interfacing with dapps. This makes the situation a little bit worse because it encourages the norm of all transactions having a to of the precompile. Ideally, signing tools would present data to users in a useful way, but it is unclear how they would do that exactly.
One option could be to instead have a precompile that functions like this, but rather than executing arbitrary bytecode it takes in an array of call_opcode,address,value,bytes tuples. The precompile would then call each address in order, passing the associated bytes as calldata and using the call_opcode for the specific call (e.g., DELEGATECALL, STATIC_CALL, CALL) and passing value ETH along with the call. This would allow signing tools to very easily/reliably parse what was happening and present the user with useful information such as "you will call these 3 contracts in this order, with this much ETH attached to each.
Further, such a thing would allow for something like Trustless Signing UI Protocol · Issue #719 · ethereum/EIPs · GitHub to present the user with much more useful informed signing details.