search

JoinColony / colonyNetwork

Colony Network smart contracts
https://colony.io/
GNU General Public License v3.0
437 stars 106 forks source link

Make all Colony contracts Gas Station Network (GSN) compatible #700

Open bmiller59 opened 5 years ago

bmiller59 commented 5 years ago

Summary

Ease of use and onboarding of new users to colonies is an important issue for broader adoption and regular use. The Gas Station Network (GSN) provides a way to support users to interact with Colony contracts without having to install MetaMask or manage their own cryptowallet by relaying their transactions for them, with the dapp/colony paying the gas costs. (Note that users could contribute fees towards the colony in other ways, for example recurring Stripe payments, etc.) Some colonies may find that this approach is better for them.

Possible Solution

Please add support for the Gas Station Network by extending Colony contracts as described here. It is as simple as inheriting from the GSNRecipient contract and changing how the msg.data and msg.sender are referenced.

This could be added to the primary contracts, or a forked set of contracts, separately deployed, if that was preferred.

If the Colony.io does not do this themselves, someone else may choose to offer a forked version of the Colony contracts with GSNRecipient, controlled and deployed elsewhere, which could cause confusion among dapp developers and users.

Context

The GSN is already available on mainnet. It is supported by a consortium of reputable organizations and appears to have been implemented in a secure way.

There is an EIP for the GSN, EIP-1613

Here is a descriptive overview article

area commented 5 years ago

Meta-transactions in general are something that have our keen interest. Many members of the team are pushing for us to support something like this, citing the same reasons (ease of onboarding users less or completely unfamiliar with blockchains in general) and solutions to potential abuse (subscription payments via more traditional third-party payment processors). I can't say it's next on our list, but it's definitely on our list! Thanks for making sure we were aware of this concrete implementation.

Note for someone working on this issue in the future: in our case, it is not as simple and inheriting the GSNRecipient contract, as in order to maintain upgradability we have to have tight control of our storage slots, but I think introducing a storage slot for it ourselves and inheriting a copy of GSNRecipient with no storage declared would work.

kronosapiens commented 4 years ago

Leaving this here for future reference: https://forum.openzeppelin.com/t/advanced-gsn-gsnbouncersignature-sol/1414