[Loopring 3.6] Support Gas Station Network for user actions

[dong77]

https://docs.opengsn.org/tutorials/

As of now, if a user must have some Ether to perform any exchange related layer-1 actions. If we support gas-less transactions relayed by GSN, users can perform those actions without Ether.

[dong77]

Without much knowledge in GSN, I have the following questions:

1. what's the minimal work we have to do besides modifying our contract to support GSNv2, as described in https://docs.opengsn.org/tutorials/#converting_a_contract_to_support_gsnv2
2. It seems a paymaster is only necessary if we want to pay the fees for our users; otherwise, we don't have to develop or deploy such a contract. The question I have is whether it is easy to frequently change the paymaster contract -- the rules should change based on our operations.
3. What's the best way to handle GSN major/incompatible upgrades? Like many apps, we don't like dependencies :)
4. How does GSN support (verify signatures of ) contract addresses as msg.senders internally, ERC1271? This seems transparent to us though.

Paymaster

how can we specify which token to charge the user as the meta-transaction fee? An example will be really helpful. In our case, we'd like to specify:

• the address of the token we want to charge the fee, 0x0 for Ether
• the gas price in that token or Ether
• the max gas the user is willing to pay

[dong77]

@Brechtpd I have this feeling that GSN will probably make our smart wallet module design simpler...

I created a PR to demonstrate how our meta-transaction modules can be re-implemented using GSN. The only part that's missing from this demo is the Paymaster contract that charges fees from each wallet.

[Brechtpd]

One of the reasons Agents exist is to support GSN or other meta transactions. I would say we want to keep these specific implementations out of the main protocol. If we do want to support one of these out of the box we can just whitelist some agents on the protocol contract so they are enabled for all users without them having to enable it specifically.

So I would say:

1. None. We just need to create an Agent contract that implements support for one or more of these meta transactions.
2. Easy to deploy new Agent contracts.
3. Easy to deploy new Agent contracts.
4. Not sure.

For payments, well, if we want people to keep their funds inside the rollup, we kind of also have to charge people for meta transactions inside the rollup I would think, that's where their funds are available. So meta txs done by us using conditional transfers for fee payments makes sense to me, and is as easy as calling approveOffchainTransfer. On the other hand, not everyone will store all their funds there, so some other way to pay may be useful as well. But I have to look more into how the Paymaster works.

I have this feeling that GSN will probably make our smart wallet module design simpler...

Probably, but on the other hand it's also one of the most important parts of a smart wallet. So if you create a smart wallet from scratch it kind of makes sense to have this built in. But I'm all for using existing services/smart contract where we can!

[dong77]

Brecht, if we create a Meta-transaction Agent, does each user has to enable that Agent before using it? The user may not have any Ether at all...

[Brechtpd]

I would allow Agents to be whitelisted by either the protocol contract and/or by the exchange owner. This way some Agent implementations can be a standard feature available to all users, so we don't have to worry about any initial gas costs for enabling those features.

[dong77]

Great, in that case, please come up with a draft implementation to support metadata tx when the time is right.

[dong77]

I would allow Agents to be whitelisted by either the protocol contract and/or by the exchange owner. This way some Agent implementations can be a standard feature available to all users, so we don't have to worry about any initial gas costs for enabling those features.

To me, this is similiar to the modules in our smart contracts.

[dong77]

I was trying to implement an Agent for GNS - OpenGSN2Agent, but I get this design problem:

Suppose Alice and Bob both trust this agent, then Bob will be able to call the exchange contract by specifying Alice as the 'from' address. Therefore, for each invocation, the OpenGSN2Agent must notify the exchange contract that the real caller is Bob, not Alice.

The idea I have is to append the real caller to the end of the call data, as we did in Hebao 1.1's ForwarderModule

[dong77]

https://github.com/Loopring/protocols/pull/1484