Meta Txs: Adding support for meta transactions in aragon apps (Part 1)

[facuspagnuolo]

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.

Approach

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:

	Gas cost
Off-chain service auth	0.5k
Refund quota validation	1.8k
Nonce validation	0.4k
Signature validation	8.3k
Log relayed transaction	3k
Reset last nonce	5.1k
Reset refunds amount	5.5k
Off-chain service refund	7.6k

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:

1. Having an on-chain relayer in charge of signature validation, nonce validation, and refunds, that will act as a middleman between the off-chain service and the target app, vs. integrating all these responsibilities within the AragonApp itself.
2. Parameterizing the transaction signer to the functions of the target app, vs. using the volatile storage approach to query it when needed without changing the app interface.

[facuspagnuolo]

Thanks for your review @bingen! Although, I think it is more interesting to review directly the last approach we decided to follow :)

[facuspagnuolo]

@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:

• Should we allow to change quotas amount and how?
• Should we allow to change quotas based period of time and how?
• Should we have different quotas per address or is it okay to have the same one for all members?
• Should we catch reverting relayed calls to ensure we always refund gas costs or should the off-chain service check if the tx will revert before relaying it?

[izqui]

Therefore, DAOs' members will be incentivized to estimate gas values correctly.

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.

Should we allow to change quotas amount and how?

I think we should, as the amount of activity that happens in the organization will change over time and the gas price can fluctuate.

Should we allow to change quotas based period of time and how?

I don't think this is really important if the amount can be changed.

Should we have different quotas per address or is it okay to have the same one for all members?

I think that having a unique quota amount for everyone should be fine for a first version.

Should we catch reverting relayed calls to ensure we always refund gas costs or should the off-chain service check if the tx will revert before relaying it?

I'd say the off-chain service should make sure that the transaction won't revert.

[facuspagnuolo]

@izqui I already addressed your comments, feel free to take another look :) I'll publish all the off-chain service stuff on a separate PR

PS: The CI coverage task is failing since testrpc does not support eth_signTypedData :/