Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Meta Txs: Adding support for meta transactions in aragon apps (Part 1) #526
The main idea of this PR is to add support for meta transactions to allow any member of a DAO to interact with its apps without having funds necessarily.
I've also started working on the off-chain functionality for the corresponding service here.
The main idea is to have shared trusted off-chain service in charge of submitting the transactions to an on-chain relayer that will be in charged of signature validation, nonce validation, and will forward these transactions to the target app if all the verifications passed. The off-chain service will get refunded by the on-chain relayer for every transaction it relays. This will allow every to manage and customize their own relayers as they want.
The following table shows the different costs added per transaction to support this approach:
Among other things, the total gas overload for a relayed transaction is ~53k of gas
Other approaches investigated
I've been exploring other approaches for this topic based on the same concept of having a shared trusted off-chain service in charge of submitting the transactions on-chain that will get refunded by the DAOs for every transaction it relays to make sure it doesn't run out of funds. The different alternatives explored are the possible combinations between the following patterns:
bingen left a comment •
More than comments I left a bunch of questions, I'm afraid I'm not fully getting it
@izqui I've decided to drop the idea of calculating the amount of gas to be refunded to the off-chain service since it was actually taking a lot of gas to perform such calculation (I reached an overload of 100k gas for some edge cases). That said, I came up with the idea of delegating the decision of calculating the gas refund to the DAOs' members. Note that off-chain services can tell whether the submitted amount of gas actually covers the costs of a transaction before relaying it. Therefore, DAOs' members will be incentivized to estimate gas values correctly.
To achieve this, I propose using a monthly quota on the relayer side to limit the amount of txs users can relay. And ofc, this triggers some new questions we should discuss:
This could be an issue if the 'service provider' can relay their own transactions (and in the current implementation it seems like any account can use the relayer), as their incentive would be to use a high gas limit/price.
I think we should, as the amount of activity that happens in the organization will change over time and the gas price can fluctuate.
I don't think this is really important if the amount can be changed.
I think that having a unique quota amount for everyone should be fine for a first version.
I'd say the off-chain service should make sure that the transaction won't revert.
izqui left a comment
A couple of aspects that we should think about: