introduced on general solidity level, this would be a breaking change, because it changes the semantic of msg.sender.
In contrast, msg.signer would introduce a new, non-conflicting semantic.
Anyone, who would like to accept both Meta-Tx and Regular-Tx would check msg.sender.
It must be explicit developer’s decision.
Oh, sorry did not get the part of the signature.
But in that case, solidity would have to do much more, because it need to reconstruct the sign message from the data passed in as a parameters. Plus as we want to support contract-account via EIP-1271 it needs to support that too.
That depends on how the contract is built. Some use msg.sender to say “the personne who paid the gas and did the call”, but most contract use msg.sender to mean “the person that signed”.
If “msg.sender” is the “meta-transaction proxy” and the user is in msg.signer, then already deployed contracts (like ERC20) would not benefit from these meta-transactions.
Also, that is what the GSN tools do: _msgSender() replaces msg.sender and returns the meta-tx signer when the call is a GSN call.
This is exactly the breaking change. Currently, the semantic of msg.sender is both - person who paid the gas and signed the tx and independent from “how the contract is built”.
This will create ambiguities for someone who audit the contract - he can be mislead about the conditions including msg.sender. May be differences will not be that huge, but consequences must be understood first before we can claim it is harmless.
How it is possible to change an implemnetation of msg.sender for already deployed contracts?
Yes, I understand you. Nevertheless, I would not mix up different implementations in the same msg.sender just because of the desired immutability of the code and its semantic.
Then onchain account based meta-transaction (like argent provides) are the only way to combine existing contracts (think of all the ERC20 tokens) and meta-transactions.
Because that is what people will want
Hey all, Just published a new EIP : EIP-2585 to solve the msg.sender problem by using a minmal forwarder.
The forwarder will not do any gas repayment or anything extra but has enough capabilities to let extension to be built.
In the demo : https://metatx.eth.link I actually built EIP-1776 on top
So while EIP-1776 support gas repayment, expiry time, etc… EIP-2585 only focus on signature and replay protection.
If we could agree on that minimal forwarder, more complex and capabale solutions like GSN, EIP-1776 or other could be built without needing receiver contract to be changed.
Would love to get your feedback
Thanks