EIP-2711: Separate gas payer from msg.sender

EIPs
41

Regarding the latest version of this EIP:

Why should the signer sign secp256k1(keccak256(rlp([TransactionType, SenderPayload]))) when TransactionType is already part of the SenderPayload

Why not just sign secp256k1(keccak256(rlp(SenderPayload))) ?

Also, in the simple summary you wrote “sposored” instead of “sponsored”

1 Like
42

SenderPayload has the TransactionSubtype, but not the TransactionType.

Will fix the sponsored typo in the morning. I have fixed the sponsored typo. :slight_smile:

43

My bad, I got confused :confused:

44

I have made 2 normative changes to the EIP:

  1. I have updated it to specify what Type 2 Transaction receipts look like, per recent changes in EIP-2718 (which requires each transaction subtype define its receipt Payload).
  2. I changed the child transaction array into a one dimensional array. This trades ~1% to ~5% size on the wire in exchange for easier human readability/understanding (an array of tuples is easier to grok and describe and talk about than a giant one dimensional array with repeated contents).

As always, feedback welcome!

45

Not sure if I missed this when skimming up top but is there a reason that it’s preferable to have subtypes [1-4] instead of the type item of the transaction envelope?

46

See the Rationale section. It was mostly for bookkeeping reasons:

[…] each of the subtypes could be a unique TransactionType. The reason we chose to go with a single EIP with subtypes is because these 4 transactions all have a lot in common and each separate EIP would be almost identical to the previous. We felt that in this case, splitting into multiple EIPs wasn’t worth the duplication of EIP content.

I wouldn’t be too opposed to having them be 4 separate transaction types, but one EIP. It would save us a byte :man_shrugging: When I wrote the EIP originally it was hard to structure and reason about when they were separate types which is the main reason I switched to subtypes. If people believe that this isn’t important enough, or have suggestions on how to structure the EIP so it is easy to understand with different types I’m open to it.

An example of where things get a bit complicated is that the SenderPayload includes a bit of data from outside the inner transaction, which means the thing signed is a merge of the outer and inner transactions. Certainly not insurmountable, just more complicated.

47

I appreciate the Rationale writeup of ValidUntil as timestamp instead of block number.

I just wanted to note some downsides of timestamp, and the proposed workarounds, like:

  • It’s harder to use validUntil to prevent the transaction being valid at the next fork (which is currently triggered by block number). Recommendations:
    • Estimate block number, adjusting based on tolerance for accidental inclusion in next fork
    • Advocate for EIP-2456 to activate forks at a timestamp
  • Other scenarios might have the same pattern as above, like the proposed ReGenesis.
    • Advocate for timestamp-based activation of ReGenesis
48

In both of the cases you have mentioned, I advocate for switching to timestamp-based activation. :smile:

1 Like
49

Hey guys, I’ve been coding some stuff using the multicall pattern, and realized that batch transactions would be similar but with even better UX.

I have two questions on how this would work for users:

  1. Would the base transaction fee be per transaction or per batch?
  2. Would it be possible to revert a batch if one of its transactions revert?
50

@albertocuestacanada I recommend checking out https://eips.ethereum.org/EIPS/eip-3074 for the latest thing we are all pushing for to achieve transaction “batching”. This EIP will probably get withdrawn at some point, just leaving it open for now until we settle on something (which is currently looking like 3074).

2 Likes
51

I agree that this should be included with the transaction batching EIP. It seems that they would be used together anyway.

52

If 3074 is included in a hard fork, I’ll probably close this one because it is no longer necessary/useful/interesting at that point.

54

Continuing the discussion from EIP-2711: Separate gas payer from msg.sender: