EIP-5806 Delegate transaction

3 Likes

One of the point I think should be discussed is the “amount” part of the transaction.

Since this transaction is going to delegate call, the amount should not be sent to anyone, and should remain on the sender/signer’s account. The delegate call mechanism cause the code that the is being executed to has access to the entire balance of the account.

Consequently, the amount doesn’t correspond to an actual transfer, and I believe it should not be part of the transaction parameters.

On the other hand, that means that the code being called through the delegate will always have msg.value equal to 0. Is that acceptable?

Amazing concept, would be awesome to have it together with EIP-3074

I think of contract storage as being tied to a specific contract. For instance, when “upgrading” contract code using create2 pattern the new code has to work with existing storage layout. So I am struggling to understand how arbitrary calls to different contracts via delegatecall will work? Sorry if this is a silly question.

I’m sorry I don’t understand.

Only contracts have storage, not EOAs. That storage is managed by the contract’s bytecode. You propose to create storage under the EOA - without any code to manage that storage. I am thinking about issues that arise when using delegatecall, such as storage collisions or the “constructor caveat” mentioned here Proxy Upgrade Pattern - OpenZeppelin Docs . How can you avoid such issues when your EOA’s storage is completely at the mercy of external contracts you delegatecall?

Is this spec final? Interested in testing this

I returned to say idea is such a great, I will try contribute.

I would suggest to disallow storage on the EOA level. We can just halt execution if the bytecode being executed is trying to store something on the EOA account. This way only calls that don’t involve this mechanism will be allowed to be included in blocks (or mempool)

Salut Hadrien,

The proposal is interersting. Yet, I’m confused about the delegatecall process originating from the EOA. When you use delegatecall , the msg.sender remains unchanged, which is similar to direct smart contract call without employing delegatecall . The distinction appears to be that the state of the smart contract would reside in the EOA’s storage. Is this the desired outcome?

I’ve identified two issues with this approach:

1.Security Concern: We often rely on eth_getCode and the fact that the storage of an EOA is ‘0x’ to ascertain if an account is an EOA. Without this distinction, it would be indistinguishable from any arbitrary smart contract. It is also the case for explorers.

2.Storage Collisions: Given that EOAs interact with various contracts, there’s a risk that variables stored in the EOA’s storage could be inadvertently overwritten, rendering the storage unreliable.

What is your opinion about having another type of call that preserves the msg.sender as in a delegate call, but uses the “implementation” contract storage such as in a ‘staticcall’?