A relayer in crypto-parlance can mean a lot of things. Still, in this context & at a very high level, it is an EOA address that can be programmatically controlled (the programmer owns the private keys of the EOA address) to sign and send transactions to the blockchain. This allows the relayer to submit transactions on behalf of a user.
In this post, we will discuss the various use cases of a relayer and how a network of relayers should function. BRN is built for these use cases and the various applications employing them. Though, in reality, each application has its application-specific logic & metadata, which could pose a difficulty in onboarding them to the BRN network. We solve this by abstracting the core relayer network operations from the application-specific logic to make the network effortlessly extendable to any future application.
Abstracting a network of relayers from its applications makes the system modular and infinitely scalable.
Relayers, as a fundamental component of the web3 ecosystem, facilitate various use cases that benefit new users entering the blockchain world and seasoned crypto veterans who have witnessed the ecosystem’s growth.
We can broadly divide the relayer use cases into three categories:
- Meta transactions - paying gas fees on behalf of users
- Cross-chain transfers - improving the multi-chain UX for users
- Automated transactions - providing transaction automation to dApps and developers
While programming the relayer node, the developer must keep the following things in check to successfully prepare and send a transaction to the blockchain:
- Ensure the nonce is set properly; a previously utilised nonce can not be used for a new transaction.
- Gas fees must be set per the respective blockchain conditions and the transaction’s desired finality requirement (fast or slow).
- The gas fee fluctuates, so the transaction’s gas fee needs to be bumped up as per the finality requirement and the changing conditions of the respective blockchain.
This complicates the relayer node design; more functionality (modules) must be added to the node to ensure it functions properly. Moreover, novel use cases like cross-chain message-passing command additional modules to provide the desired user experience.
Users familiar with web2 applications, like social media or banking apps, may anticipate a similar experience in web3. However, the way users interact with an application in web3 differs significantly from that of web2.
Blockchains are nuanced in their approach to security & resilience to DDoS attacks. For example, since a single entity does not have full control, authentication in web3 is distinct from web2. Unlike the “free” interaction with servers that web2 users enjoy, there is an inherent cost to every interaction in web3.
The authentication mechanism requires one to create a wallet (a public-private key pair), and the interaction cost must be paid in the chain’s native gas token. Now imagine using an application in this world for the first time; all necessary steps must be completed independently, including obtaining the chain’s native gas token, which can be akin to participating in an Olympic sport.
This is where the concept of a meta-transaction shines and helps user onboarding.
The user doesn’t need to have gas tokens. They just sign, and the application logic sends this transaction along with the user’s signature data to the relayer. The relayer prepares a special transaction that has the user’s context and sends it to the blockchain while managing the gas fees and nonce (i.e., all the things that need to be considered while sending a transaction mentioned above)
The transaction gets finalized on the blockchain without the user knowing anything about the chain’s native gas market or nonce management.
This is a superpower that a relayer unlocks in the EOA universe.
At a very high level, a cross-chain transaction works in the following manner without a relayer:
- A user signs a transaction on the source chain to send some assets from the source chain to the destination chain. The user pays the gas fee for this interaction in the source chain’s native gas token.
- An event is generated when this transaction is added to the source blockchain.
- The backend system listens to this event and creates a new transaction for the destination chain, showing the user a pop-up on the UI. Note that, based on where the protocol lies on the decentralization spectrum, there can be multiple ways of ensuring the correctness of the source transaction vis-à-vis a PoS validator system or a centralized service polling the blockchain, looking for new events.
- The user approves the transfer conditions and agrees to the associated fees. This opens a meta-mask pop-up for the user where they sign this transaction on the destination chain. Keep in mind the user needs to have the destination chain’s native gas token as well to be able to send that transaction to the destination blockchain.
- Some time may pass for all parties to become comfortable with the source chain transaction integrity. During this time, the user needs to ensure that the destination transaction is not stuck and bump up the fees for the transaction to succeed.
- At the end of the destination chain transaction, the user receives their fund on the destination chain.
We can improve this user experience by offloading steps 4 & 5 to a relayer that prepares and sends the destination chain transaction. In other words, the relayer ensures the funds are sent to the user without the complicated user experience showcased above.
Every interaction with the blockchain requires an EOA signature; hence if the user wants a transaction to be triggered based on some external data, they will have to do it manually.
A relayer, in this case, can ease the experience by preparing and sending the transaction to the blockchain on behalf of the user. This is achieved by having a backend system that can monitor the blockchain for certain events and, based on the trigger, sends the relevant transaction to the blockchain.
The Biconomy Relayer Network Abstraction
The Biconomy Relay Network (BRN) is a network of such relayers that help facilitate transactions originating from applications employing these use cases.
We are designing the BRN such that network operation is abstracted from application-specific use cases, which means any logic related to a use case should not interfere with the network’s core functions.
Critically, the network has to ensure that:
- There is no destructive competition among nodes. We solve this problem using a novel transaction allocation mechanism.
- Nodes with a large network share get more transactions vis-à-vis more rewards. Our economic model is built keeping this in mind.
- The system is reliable with built-in redundancy & the network is resilient to malicious actors and exploitative attacks. More on this coming soon.
We will continue posting details about the various components of the network in the forum.
Share your views on the design and ask probing questions. Let’s make the system more robust, resilient & future-proof.