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!