Thoughts on implementing a WhitelistedGSNRecipient

General
1

Hi all, I have been playing with the latest OZ 2.4.0 GSN changes.

Adding this to one of our projects and looking at the GSNRecipientSignature which takes a single approved signer - it feels obvious to extend this to be driven from a whitelist.

I have made a simple mock up of this but wanted to run it by you and seen if there is a known reason you wouldn't or haven't included this in the initial GSN release.

Cheers

1 Like
2

Hi @jamesmorgan,

Welcome to the community forum :wave:

Just to confirm, do you want to have multiple trusted signers, to sign your users relayed call parameters (https://docs.openzeppelin.com/contracts/2.x/gsn-strategies)?

I can understand wanting to potentially extend GSNRecipientSignature to add an admin role that could set the current trusted signer.
I was curious to understand why you might need multiple trusted signers?

I recommend looking at the following tutorial (if you haven’t alread): Advanced GSN: GSNRecipientSignature.sol

3

Hello @jamesmorgan! Welcome to the Forum! :slight_smile:

GSNRecipientSignature I think was intended to be a simple use case to start users out. You can certainly create your own bouncer based on this and implement the kind of logic you are talking about! Feel free to share your results here, a more robust system of managing signatures would surely be welcome.

thanks!

1 Like
4

Thanks for the comments guys, I may have miss understood what acceptRelayedCall() should be used for but this is my use case:

  • We are developing a backoffice tool which allows a specific company to tokenise things (ignoring what these things are for the time being)
  • At the moment we have a minting contract which has an access control role that is given to several staff members allowing them all to minting
  • ATM all these accounts need to have some ETH to mint tokens and the balance need to be topped up from a central source
  • I would like to extend the GSNRecipient to be whitelist aware so all those accounts who can mint, should be able to send in txs to the relayer

This is the first pass of the code.

        // Ensure signer is whitelisted
        if (isWhitelisted(keccak256(blob).toEthSignedMessageHash().recover(approvalData))) {

            // Ensure transaction fee without acceptable bounds
            if (transactionFee <= maxTransactionFree) {
                return _approveRelayedCall();
            } else {
                return _rejectRelayedCall(uint256(WhitelistedGSNRecipientErrorCodes.TRANSACTION_FEE_TO_HIGH));
            }

        } else {
            return _rejectRelayedCall(uint256(WhitelistedGSNRecipientErrorCodes.SIGNER_NOT_WHITELISTED));
        }

Hope this makes sense.

Cheers

1 Like
5

Hi @jamesmorgan,

My understanding of your use case is that addresses who can mint tokens should be also able to use the GSN.

If you are creating a new token, then you could create a Custom strategy to check in acceptRelayedCall if the from address had the minterRole and if so approve the relayed call, otherwise reject.

If you are creating a contract that has the minter role for your token, then you could add a WhitelistedRole and check that addresses were whitelisted to call the mint functionality and also in acceptRelayedCall to check the from address was whitelisted.

GSNRecipientSignature uses an off-chain service signing (using a single trusted signer) the relayed call parameters of the users making calls via the GSN to the recipient contract. In your case this would result in an off-chain check that addresses were whitelisted to use the GSN and an on-chain check that addresses were allowed to mint.

As an aside, assuming that the users who can mint are using MetaMask, then you can create a dapp that uses MetaMask for addresses to sign a relayed call:

1 Like
6

Hi @jamesmorgan,

I just wanted to check in and see if you had any more questions on a whitelisted GSN recipient?

1 Like
7

A post was split to a new topic: How to test/use the GSN network locally