Meta transactions, Oil, and Karma megathread

[pipermerriam]

I’m going to get another write-up on this done later this week but right now, the most promising approach I’m seeing is:

1. Separate “gas payer” from “transaction sender”
   • Exact mechanism still TBD
     • Extend transaction format to allow optional “gas payer” signature. This change must be backwards compatible since there is a LOT of existing tooling and infrastructure bound to the current format.
   • Aimed at replacing the existing meta-transaction mechanism. Would need to be rolled out ASAP to give time for migration from old “deprecated” approach.
   • Need to investigate whether we also need in-protocol atomic batching of transactions.
2. UNGAS:
   • Breaks current meta-transaction mechanism
   • Allows us broader latitude to reprice operations (specifically for witness gas accounting)
   • Will need to do analysis to find what contracts will break and address those breakages individually as we become aware of them

It appears that with these two changes we get the freedom to reprice opcodes for witness gas accounting and better mechanism for implementing meta-transactions. Next steps are 1) validating that there isn’t something missing here and 2) starting work on formalizing the specifications for both of these changes with specific thought towards getting the decoupling of gas-payer/txn-sender into a fork asap since there will be a need for time between rolling that out and rolling out UNGAS to give people time to upgrade.

[pipermerriam]

Some more notes on separating “gas payer” from “sender”

• Contracts need to be able to identify who gas payer is.
  • We can possible use ORIGIN for this. Need to investigate if there are any problems with using this approach.
• Contract needs a mechanism for paying the gas payer for the gas used.
  • UNGAS will make the current approach of measuring no longer viable.
  • GAS_LIMIT would be under the control of the sender so contracts can just use GAS_LIMITto compute payment amount which will tend to overpay the gas payer but this seems ok and can be mitigated with good gas estimations.

Assuming the current transaction parameters are:

txn = [to, nonce, data, value, gas_price, gas_limit, v, r, s]

A transaction with a separate gas payer transaction would include another nonce, v, r, s which signs the whole txn (including the sender’s signature).

txn = [to, nonce, data, value, gas_price, gas_limit, v, r, s, gp_nonce, gp_v, gp_r, gp_s]

This naive approach has some problems.

• One could monitor the transaction pool, find these transactions, strip out the gas payer signatures and replace them with their own (Sniping?)
• One could strip off the gas payer signature and just broadcast the base transaction parameters (which should be a valid transaction)

So it seems we need a mechanism to provide the following assurances…

• Ensure that the base transaction parameters cannot be stripped out and broadcast in isolation
• Explore what guarantees we need for the sender and the gas payer
  • There are definitely situations where sender should be able to sign without knowing gas payer…
  • Do we need a way for sender to designate gas payer…
  • Are there cases where gas payer needs exclusivity (outside of being explicitely specified by the sender).

[3esmit]

Hello everyone,

I am happy to see interest on enabling gas abstraction in protocol level, thanks for the effort of everyone, as this is a very important improvement for the Ethereum ecossystem and UX.

I am quite unsure if I am missing something, because for me it looks like all these meta transactions proposals are over complexing something that can be solved in a more generic and simple matter. I would not be covering the issues with repricing or the proposal of Oil/Karma in this post, so this contribution is solely related to the gas abstraction effort.

I’ve been researching on the gas abstraction since Jan 2018 (see details here), and since the beginning the idea I had in mind was to propose a soft fork of the miners to allow them to accept gas relayed transactions.

There are mainly 3 types of gas relayed transactions I identified:

• Contract operated in ERC20 Token Contract (as in ERC 865)
• Contract operated in Singleton Contract (as in Tornado Cash, or Alarm Clock)
• Account operated (as in ERC 1077)

As one of the authors of ERC1077, together with @alexvandesande, I plan to update 1077 to bring a standard for all those types, but currently 1077 only defines for account contracts. I already updated 1077 to be more generic and less memory intensive, by using less parameters in the method signature.

With such standardization, I started two more EIPs to fully integrate the 1077 within the protocol:

• Gas Abstraction (EIP 2473) which proposes a soft fork for miners/validators to be able to recognize and directly include this transactions
• Coinbase calls (EIP 2474) to reduce the processing cost of gas abstracted calls.

In regards of 2473, the idea is that, similar how to regular transactions work, the validators can validate the outcome of transactions and decide if they are worth including, and if so, include them with a gas price 0. There is no need of protocol upgrade for implementing this, is a soft fork which only changes how miners/validators pick and include transactions in blocks. This would solve the “relayer network” dilemma, because now miners would be able to directly accept any tokens they choose.
Whisper would be used to communicate such transactions, but each token address would have it’s own topic.
This also would solve the problems of relayers networks for Tornado Cash, as said here.

2474 improves the gas abstraction, making such calls safer and cheaper, as they won’t have anymore the regular “outer transaction”, instead, validator would be able to call limited functions in contracts directly. This limited functions would simply be calls which don’t access msg.sender, tx.origin, neither gas.price. where such calls could render a invalid jump or a hardcoded value.

All those EIPs are a current work in progress which everyone here is invited to participate and become authors, by simply providing any improvement to those proposals. Currently I let them aside as no one showed interested in them, and instead are trying to create different solutions I don’t understand/agree, but if there is interest I can get back in that research.

Anyway, I would be happy with any solution that allow users to seamlessly transfer ERC20 tokens paying gas in the token itself (or other token they choose), so if maybe I am in the wrong direction here I can just let you solve this issue and focus on other research.

Please, let me know if I am missing something and why the solutions I propose are not good enough, or what are the weakness of them, I’ll be happy in researching solutions on this topic, and/or updating them to the contexts of EIP-1559/Oil/Karma. Thank you all for the hard work!

[matt]

Agree with your points above.

@pipermerriam

A transaction with a separate gas payer transaction would include another nonce, v, r, s which signs the whole txn (including the sender’s signature).

Regarding this, it seems simpler to not include the sponsor’s nonce. Because the base transaction has a unique hash (protected by the signer’s nonce) the sponsor’s signature on that transaction will only ever be able to be accepted once. This removes the need to construct a more complicated dependency structure between the the signer and sponsor nonces.

For example, suppose we have the following contents in the mempool and a new incoming transaction:

Visually, it’s clear that TRANSACTION TUPLE 4 depends on TRANSACTION TUPLE 3, which in turn depends on STANDARD TX 1 – the transaction that would be replaced by 4 since they both have nonce of 1 for account A, and therefore it is invalid. This adds a lot of complexity to the existing rules in the mempool. I believe the best two approaches for validating an incoming transaction with dual nonce dependencies are to either i) do a cycle check on the dependency DAG or ii) maintain a state diff for each tx. Neither scenario seems ideal.

When the sponsor’s nonce is not included, transactions can be accepted, rejected, and substituted in a much more similar manner as they are today. The sponsor’s balance acts like an amorphous accumulator that has no ordered dependencies to maintain – just ensure it’s balance is greater than value + gas_price * gas_limit of the transaction it’s accepting and when a transaction they’re sponsoring is demoted, replenish their balance with the demoted amount.

The main casualty I see from dropping the nonce is that the sponsor won’t easily be able to cancel their transaction by issuing a new one with the same nonce and much higher gas price.

–

the validators can validate the outcome of transactions and decide if they are worth including, and if so, include them with a gas price 0

A few thoughts on this:

• validating a transaction at the consensus layer would cost O(n) since it could pay out in tokens at the very end of execution. Maintaining O(1) cost of validation should be a goal at the protocol layer. This could be remedied via a configurable parameter set by miner.
• it’s not clear what standard set of tokens will be accepted by miners – some esoteric token may only be accepted by a few miners and therefore the latency could be very high. Even if a small number of relayers accepted an esoteric token, there would be no degradation in latency.
• this seems to necessitate a lot more infrastructure for miners: rate negotiation endpoints, watch lists of tokens and conversion rates, validator logic watching the miner’s accounts on various tokens before and after execution, etc.
• dapps who want to onboard users may be willing to altruistically sponsor their users’ transactions, but this scheme seems to only cater more to a 1:1 relationship between the miner and signer

This is an interesting alternative though and it should not be overlooked. I think as we flesh out all proposals more we’ll better understand the advantages and disadvantages of each.