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ā?