Gasless Transactions

Removes the user need of having native tokens to interact with any dApp in Coqnet

Overview

Gasless transactions represent an enhacement in Blockchain user experience. It could be tiring to prompt the wallet every time there is a transaction to be signed, specially in the context of games where the state changes often. Let's explore two primary implementation approaches and their implications:

Implementation approaches

1 - Backend Relay Model (CoqPot approach)

This model abstracts away the transaction interaction required between the end-users and dApp while mantaining the security and transparency that Blockchains offer. The trusted backend receives a delegated role to manage interactions on behalf of the users.

Operational Flow

• The end-user starts a wallet connection with a particular dApp by providing his signature

• The end-user interacts with the UI and performs certain action within the dApp

• The backend service validates the user request against certain predefined parameters

• The backend's task is to build and validate a proper transaction that won't fail when it is executed

• The smart contract has role-based protected methods

• The backend by using a particular role is authorized to call certain methods in the smart contract

• The smart contract process the transaction

• Once the transaction is confirmed in the Blockchain the results are propagated back to the user interface

• User receives feedback of his operation

User Experience Enhancement

• Single intial wallet authorization (replaces login in Web 2.0)

• Seamless transaction execution

• Immediate response feedback

• No recurring signature requirements

Implementation Example

The Cop Pot Bonanza game has implemented the delegation-to-backend pattern. To begin with, there is a signer (public key and private key) within the backend that signs transactions. The smart contract gave to the backend signer a particular role to access its protected methods. For instance, in the following code snippet we have the method spinForUser.

function spinForUser(address player, uint256 betAmount, uint256[3] memory randomWords)
    external
    onlyRole(RELAYER_ROLE) // <-- role here!
    returns (uint256[3] memory landedSymbols, uint256 payout){}

Thanks to the Open Zeppelin library, that method is protected and only those signers that have the RELAYER_ROLEwill be authorized to call it.

Risks of the delegation-to-backend pattern

While this is a functional pattern, it is not absent of risks. The backend becomes a single point of failure. Any disruption could lead to an inoperable dApp. On top of that, users must trust the backend integrity and, potentially speaking, the backend could censor or filter certain transactions.

With today's technology it is possible to mitigate those risks. For instance, the backend could be deployed in multiple regions and have redundancy layers. Multiple backends and failover mechanisms could prevent any interruption in the service they provide. In regards to the second risk, if there is a limited scope, strict role-based acces control and constant monitoring, the backend signer has limited capabilities.

2 - Meta-Transactions (EIP-2771)

Meta-transactions enable users to interact with smart contracts without holding native tokens for gas fees. This is achieved by separating transaction signing from transaction execution, where a third party (relayer) submits the transaction and pays for gas while the user only signs a message authorizing the action.

There are important distinctions compared to the first model listed below:

Meta-transactions

• Users must sign each single action

• Relayer can't modify or alter the user's intent

• The actions are limited to the parameters that were signer

• More decentralized since any relayer can submit the transaction for execution

Backend Relay

• Users are not required to sign any transaction

• Potentially speaking the backend could alter the user's intent

• Trust in backend is required

• Centralized execution

Operational Flow

There are at least four parties involved: the end-user, dApp, Relayer and Contract.

• User interacts with the UI and initiates an action that declares his intent

• The dApp request user's signature for a very particular action

• The user signs a structured message (not a transaction) that involves no fees (off-chain)

• The dApp sends the signed message to the Relayer

• Relayer shapes an actual tansactions and submit it to the Smart Contract

• The Smart Contract verifies the signature and executes the transaction

• The Smart Contract propagates the result to the UI and the end-user receives feedback

For more information in regards to the second model find it here.

Both approaches definetely enhance the user experience, each with its own strengths and trade-offs. The Backend Relay Model, as implemented in Coq Pot Bonanza, offers simplicity and seamless user interaction. The Meta-Transactions model provide additional security through explicity user consent and decentralized execution.