How to develop gas station for dApps?

Ever since Blockchain technology has become prominent, rapid contributions have been happening in that space to make the technology more usable in the real world. From immutable record-keeping to automated smart contracts to decentralized applications, the utility of blockchain is scaling up to new heights very rapidly. As you know, the Gas fee is the fuel that powers every transaction over the blockchain. Be it the simplest transaction like Mr. X sending cryptos to Mr. Y, executing a smart contract, or using a dAPP, the user needs to pay the Gas fees with crypto tokens. While the Gas fee is necessary to compensate for the computing energy that goes into transaction processing and validation, the Gas fee is also the reason that restricts the broad adoption of decentralized apps, especially among the users who have no prior experience with cryptos.

To use a dApp, the users first require onboarding with a cryptocurrency to pay Gas for transactions. It means, before interacting with the dApp, the users must create a crypto wallet, go to an exchange, and buy the relevant cryptocurrency to be used as a gas unit. So clearly, a user interested in using a dApp faces a lot of friction in the onboarding process, which impacts dApps adoption at a broader scale.

Is there a way out to reduce the onboarding hurdles for dApp users? The solution lies with the Gas station. A gas station pays the gas fee on behalf of the user under certain conditions and relieves them from acquiring crypto tokens in advance of signup. This article will discuss the concept of a Gas Station in detail and how to develop gas station smart contracts.

• What is Gas Station Network (GSN)?
• What is the Architecture of Gas station?
• How to Develop Gas Station?
• Develop Your Gas Station with LeewayHertz

What is Gas Station Network (GSN)?

Gas station Network is a blockchain-powered decentralized system that allows gasless clients (users) to interact with dApps without paying crypto tokens for the transaction fees. The payment of the Gas fee on behalf of the users is carried out by a Gas station, which can be understood as an account (a relay server) that exists only to fund the gas payments.

GSN use cases can offer the following benefits:

• Users can pay Gas in any token.
• Users not wanting to go through KYC can pay Gas in Fiat.
• The subsidized or hurdle-free onboarding process for new users.
• Improved usability of a dAPP without sacrificing security.
• Users with no prior crypto experience can use dApps without keeping crypto tokens in their wallet for Gas.
• It also resolves the UX pain for existing users, who need to continually replenish their crypto balance to pay gas fees despite having tokens in their wallets.

What is the Architecture of Gas Station?

Let’s understand how Gas station network works-

1. The Client Sends Meta Transaction to the Relay Server

Within the GSN architecture, the client or user doesn’t require signing a blockchain transaction; rather, he signs a message containing the information about the transaction and sends it to a relay server. This is referred to as signing & sending meta transactions to the relay server. The relay server verifies the transaction information and pays for the Gas. As the client doesn’t sign for a blockchain transaction, he doesn’t require to pay the Gas fee.

2. Relay servers

Every dApps can deploy its relay server and provide service-at-cost to its users. If a dApp doesn’t have its relay server, its users can route their meta transactions through the third-party relay servers.

3. Paymaster refunds relay server for gas fees

Paymaster has a tank of crypto tokens in the RelayHub. Then there are Paymaster contracts that contain all access control and gas refund logics of a GSN. These contracts can implement any business logic to decide whether to accept or reject meta transactions. Paymaster’s gas tank refunds the relay server’s gas fee costs whenever the paymaster contract accepts a meta transaction.

4. Trusted forwarder contract

To strengthen the security within the GSN, the transactions are promoted through a Trusted Forwarder Contract. This contract is responsible for verifying the signature and nonce of the original sender (the client). Meta transactions warn the Recipients to rely on trusted Forwarder Contracts only.

5. Relay hub facilitates trustless connections among the participants

There are three participants in a gas station network – the client (sender), the relay server, and the Paymaster. The RelyHub connects all the participants without having to know or trust each other. The dApps developers can integrate with a GSN networking without understanding the inner working of the Relayhub.

The RelayHub facilitate the following:

• Clients can discover the best third-party relay servers when the relay servers of their own dApps are down.
• It prevents third-party relay servers from censoring transactions.
• It ensures that the Paymasters payback the gas fees and transaction fees to the relay servers.

How to Develop a Gas Station?

As you know now that by developing a Gas Station for your dApp, you can provide simplified onboarding to your new users. They don’t require holding crypto tokens as you pay for the transactions on their behalf.

To make your dApp Gas-station enabled, you require developing a Gas station-capable smart contract. Here are the steps explained:

Note:

The following example of programming code applies to Ethereum Gas-station network:

      1. Receiving a Relayed Call

First, a recipient needs to inherit from Ethereum’s BaseRelayRecipient contract. Adding BaseRelayRecipient makes the token contracts GSN-callable.

import "@opengsn/contracts/src/BaseRelayRecipient.sol";
contract MyContract is BaseRelayRecipient {
...
}

Points to Note:

When working with GSN recipient contracts, never use msg. sender or msg. data. On relayed calls, msg. sender is the Forwarder contract and not your user’s contract. Despite that, you will be able to retrieve your user’s address.

   2. Paying for your user’s meta-transaction

Relay servers pay on behalf of your users, but that is not any charity, so you need to make refunds to the relay servers and cover their expenses. It happens through the special contract called Paymaster.

So, next, you need to create a contract that inherits from BasePaymaster. Here, you will require to implement two methods: preRelayedCall and postRelayedCall

    3. Setting the getGasLimits and acceptanceBudget

The RelayHub enquires your Paymaster contract regarding the amount of Gas it will require to execute all the logic in the preRelayedCall and postRelayedCall methods.

function getGasLimits()
external
view
returns (
GasLimits memory limits
);

If the Paymaster consumes the gas limit, it will be charged for its transactions.

    4. preRelayedCall

Now, the RelayHub will ask your Paymaster contract if it wants to receive a relayed call. Here, to avoid consuming more than acceptanceBudget Gas, you should only accept calls that you’re willing to pay for. For that, you can choose to accept calls only from a whitelist of trusted users or calls to an onboarding function or delegate the acceptance logic off-chain.

function preRelayedCall(
GSNTypes.RelayRequest relayRequest,
bytes approvalData,
uint256 maxPossibleGas
)
external
returns (
bytes memory context,
bool rejectOnRecipientRevert
);

If you decide not to accept a relayed call, the function will revert back.

    5. postRelayedCall

Once you accept a call and the actual relay call is made, the RelayHub will allow your Paymaster contract to charge your user for their call. This function is named as postRelayedCall.

function postRelayedCall(
bytes context,
bool success,
bytes32 preRetVal,
uint256 gasUseWithoutPost,
GSNTypes.GasData calldata gasData
) external;

postRelayedCall is a natural place to charge your users because it gives you an accurate estimate of the transaction cost (Gas needed for postRelayedCall itself is not included)

       6. Delegating the preRelayedCall logic to Recipient

If you have noticed, there is a boolean return parameter called rejectOnRecipientRevert in the preRelayedCall function, it is set to true. It allows the Paymaster to delegate the decision of whether to pay for the relayed call or not to the Recipient. The Paymaster pays off in one of the two scenarios.

• The Recipient call is successful
• The Recipient call got reverted, but it consumed more than acceptanceBudget Gas.

You should use the rejectOnRecipientRevert parameter only if you can write and audit both the Paymaster and Recipient to establish them as trustable components.

       7. Trusted Forwarder

Once your contract becomes GSN-capable, it will be able to handle your dApp’s user authentication. Afterall, GSN is a network of third-party contracts, so you may feel the need to verify and audit all the functions and codes of GSN.

To help you out, a GSN project provides a default implementation of the Forwarder contract. This contract validates the sender’s signature. This way, it shields your BaseRelayRecipient contract from any potential vulnerabilities across the Gas Station Network.

Endnote- Develop Your Gas Station with LeewayHertz

Whether you are looking to integrate GSN into your exiting dApp, or are willing to develop a new GSN-capable dApp, at LeewayHertz, we can provide you with an end-to-end solution. Our GAs station services include:

• Development of GSN-capable smart contracts
• GSN deployment addresses
• Adding GSN support to exiting dApps
• Deployment of the relay server,
• Security audits

To get Gas Station solutions for your dApp projects, please connect with our blockchain experts.