EIP-2711: Separate gas payer from msg.sender

[matt]

@MicahZoltu

I added some more text about the nonces a bit ago, do you think I should add more or is what is now there good?

I’m looking at this as the most updated link, let me know if this is wrong. Under the nonce rationale you’ve listed payload size and deadlock as the problems with requiring a sponsor’s nonce, but I feel like increased cost of validation is biggest concern. I’m not sure if you intended it that to fall under deadlock, but I think it is slightly different and worth mentioning.

@MicahZoltu

That being said, the rationale section may get value from including specific things that were not done if it is not intuitive why they weren’t chosen. Do you have specific things you can think of that should be mentioned in the rationale?

I agree with you, we should avoid giving a history lesson within the EIP. However, I believe that it is worth mentioning that this EIP by itself does not solve the relayer payment problem. For that we really need something like rich transactions or batched transactions. I wrote about this need more here.

@Amxx

Proposition:

• Keep the “internal” transaction similar to the current ones. They include gasLimit, gasPrice and signeture by the “signer” (msg.sender). This can be submitted and mined like currently
• Wrap them by adding an overloaded gasPrice and the signature of the “relayer”.

What do you see as the advantage of this method? At first I was thinking maybe we don’t need to change the tx structure, but if you don’t and introduce some sort of precompile for the relayer to send to then you’re going to link together the signer and sponsor’s nonce - which I think is a problem.

@Amxx

If I had to chose I would trade in a name I don’t like for support that would bet this EIP into a hard fork / network upgrade.

I agree, I don’t want to get hung up on a name it means no support. However, I think being precise in naming is valuable - especially in a technical field. The people I’ve spoken to 1:1 regarding this find it is a more suitable name and appreciate that it is not overloaded with other meanings. Sponsored transactions clearly explain what this EIP is proposing. There is nothing “meta” about the transaction format here, everything is explicit and defined in the protocol. For those reasons, I think it is an appropriate title for this EIP.