The BRN (Biconomy Relayer Network) aims to address the challenges associated with organizing a group of relayers in a blockchain environment. The main idea is to create a mechanism where independent relayers can collaborate and provide relaying services in a more organized and reliable manner.
While individual relayers can perform this task on their own, the BRN proposes that applications benefit from being supported by a group of independent relayers. This collective approach ensures greater system reliability, as even if one relayer fails, the others can maintain the operability of the system.
The challenges faced in organizing a group of relayers include:
- Integration with different applications: The BRN needs to integrate with various applications that require transaction relaying services seamlessly. This integration should be smooth and efficient, allowing applications to leverage the benefits of the relayer network.
- Competition among peers: Since multiple relayers may be part of the network, there can be competition among them for relaying transactions. This challenge must be addressed to ensure fair and efficient transaction relaying without favoring any specific relayer.
- Transaction management: Managing and coordinating transactions within the relayer network is crucial. There may be a need for protocols and mechanisms to handle transaction verification, sequencing, and other related tasks to maintain the integrity and consistency of the blockchain.
- Reimbursement: Relayers provide their services, and it is essential to establish a fair reimbursement mechanism. This involves determining how relayers are compensated for their efforts and ensuring that the incentives are aligned for active participation and continued support of the network.
To overcome these challenges, the BRN is built with three core components:
- Smart Contract Core: This component includes the smart contracts that define the rules and logic of the relayer network. It governs the interaction between applications and relayers, ensuring proper integration and coordination.
- Application Management Contracts: These contracts handle the integration of different applications with the relayer network. They facilitate the onboarding of applications, define the requirements for relaying transactions, and provide necessary interfaces for application-relayer interaction.
- Relayer Node: This component represents the independent relayers that form the network. Relayer nodes execute the relaying tasks, verify transactions, and contribute to the overall operability of the blockchain system. They interact with the smart contract core and application management contracts to fulfill their role effectively.
By combining these components, the BRN aims to create a collaborative and reliable environment for transaction relaying in blockchain applications, addressing the challenges of integration, competition, transaction management, and reimbursement.
General Description.
Relayer: these are entities or individuals that run a Relayer Node. The Node code is open-source and maintained by Biconomy and the community such that its operation is simple and straightforward. In order to participate in the network, relayers should register in the intermediary contract (see below). and stake BICO tokens.
Intermediate Contract: This is the heart of the BRN. It oversees relayer registration, their stakes, and relayer selection based on a Probability Mass Function derived from the number of BICO tokens each relayer stakes. This implies that the more tokens a relayer stakes, the higher the chances of their selection to relay transactions. Consequently, a greater number of transactions are allocated to committed relayers who contribute to the smooth operation of the network. Relayers who fail to execute transactions face penalties. Continuous non-compliance with the network rules may lead to the relayer being placed in âjailâ for a predetermined period, as will be explained later.
Applications: These are systems that necessitate the relay of transactions. For example, meta transactions are a specific type of application where users ask relayers to submit transactions on their behalf and are prepared to pay for gas in currencies other than ETH. Various applications can be integrated into the BRN using an interface contract, which includes systems for cross-chain transactions such as bridges, automation, and more.
Users: Depending on the applications, users may either directly interact with the relayers or with the applications themselves. Meta-transactions serve as an example of the former, where users engage directly with relayers. In contrast, automation and cross-chain transactions exemplify the latter, where users interact with applications. In these instances, relayers receive information via the blockchain or other third-party systems implemented by the application systems, such as the Guardian network of Wormhole.
Relayer registration
Relayers are required to operate a Relay Node and register their public keys in the intermediate contract by staking a minimum quantity of BICO tokens. This setup guarantees that relayers are incentivized to act appropriately. They are compensated for their services through transaction premiums and BICO token rewards. For a deeper understanding of the BRNâs economic model, please go here.
Relayer selection.
In order to avoid competition and losses in the form of failed transactions when two or more relayers attempt to submit the same transaction, we use multiplexing. This consists first in dividing the time in windows of N blocks. Within a window, a group of relayers is selected to relay transactions.
More formally, given R, the full list of relayers, a subset r of length n is drawn using a probability mass function (PMF) built from the individual ratios of staked $BICO by individual relayers to the global stake of the network. Let S be the total staked $BICO in the network and s_i the amount of stake of the relayer r_i, such that S=\sum_{i=0}^{n-1}s_i. The probability of selecting r_i is given by p(r_i)=s_i/S and \sum_{i=0}^{n-1}p(r_i) = 1.
Members of the set r are allowed to submit transactions in a time window of fixed length. This selection changes every N block. N is a parameter of the network.
The image below describes the relayer selection mechanism assuming N=5. and a number of relayers per window N_R=2.
The selection mechanism consists of drawing N_R random numbers based on the PMF, such that relayers with higher stakes are more likely selected.
It is important to note that the relayer selection is a passive process, that is, a relayer is checked against the selection only when it submits a new transaction to the intermediary contract, meaning that there is no need to submit a special transaction for this to happen. This verification can be done efficiently at the level of smart contracts with no significant overhead for the users.
Transaction allocation.
Transaction allocation verification occurs at the level of the applicationâs contract interface. The general mechanism typically involves using the hash of the call data or specific parameters within the call data, though the exact details vary from application to application. This generated hash is then employed to randomly select one of the relayers from those previously chosen in the Relayer selection process. Given that the hash valuesâ expected distribution is uniform, the transaction allocation among the selected relayers is likewise uniform. A relayer may be chosen twice within the same window, leading to an allocation of more transactions to that relayer. This scenario is particularly expected for relayers with a significant stake in the system.
To decrease the overall overhead cost per relayed transaction, multiple user transactions can be consolidated into a single batch by the relayer. The system enforces this process, allowing each relayer, selected within a given window, to submit only one batch transaction.
Transaction allocation functions as a passive mechanism. The intermediary contract doesnât need to be aware of available transactions to allocate them; instead, each relayer can independently verify which transactions will be allocated to them based on the hash of the call data (or specific transaction data defined by the application) and submit the batches accordingly. The intermediary contractâs role is solely to confirm the accuracy of the allocation using the transaction data. As a result, thereâs no requirement for the intermediary contract to store data for this verification. Moreover, the verification process, which involves hashing data and using the output to index the results of the relayer selection, can be executed efficiently at the level of smart contracts.
Itâs important to note that relayers can perform these verifications off-chain, as both the selection and allocation can be predicted before the start of a window, given a set of transactions received by the relayer via the blockchain, users, third-party networks, or other relayers (via a P2P network among the relayers).
Liveness
The mechanism described above allows multiple relayers per window and partitions the transaction space so that the network continues to function even if several relayers are offline. If a relayer fails to execute transactions, these transactions become available to other relayers in the following window. However, while the liveness of relayers doesnât halt the system, it does impact its performance. The BRN enforces certain rules to guarantee a minimum level of liveness.
Each relayer r_i has a probability of being selected p(r_i) that equals to the proportion of the total staked BICO that was provided by the relayer. This process can be modelled using a multinomial probability distribution, where each relayer has a fixed probability of being selected. Given a total number of transactions N_{tx} executed by all the relayers in a period of time (epoch) each relayer is expected to be selected N_i times, where N_i is given by N_i=N_{tx}*p(r_i). We use this statistic as a mechanism to verify the compliance of the relayer. We calculate a confidence interval with p=0.9999 for the expected number of transactions using a normal approximation. The range of expected transactions executed by the relayer r_i, T_{r_i} is given by: T_{r_i}=N_i\pm Z*S(r_i) where S(r_i) = \sqrt {N_{tx}p(r_i)(1-p(r_i))} and Z is a factor that determines how many standard deviations the measured number of transactions can deviate from the expected number. In our case Z = 4.
Any relayers for which the number of transactions falls below the lower limit of the range after an epoch, is penalized according to the BRN economic model.
Notice that the equation that defines the range, is more flexible in epochs with lower number of transactions N_{tx}.
This mechanism is being continuously tested in a local deployment to ensure that the theoretical specifications fit what is observed in practice, these scenarios include epoch with a high number of transactions, epochs with low number of transactions and simulated failures by relayers.
The image below depicts one of the many scenarios tested. It presents the networkâs state over a 10-hour epoch during sub-normal operation, where only one relay transaction is requested per window (underuse of the network) for 10 simulated relayers, each with a different stake in the network. As demonstrated below, the estimates of executed transactions align with the expected values.
When a relayer consecutively fails to submit transactions to the extent that the total number submitted per epoch falls outside the corresponding range, it is temporarily put in âjailâ. During this jail period, the relayer doesnât receive any transactions, thereby increasing the selection chances for all the remaining well-behaved relayers.
Conclusion
In conclusion, the Biconomy Relayer Network (BRN) provides an innovative solution to the challenges associated with organizing a network of independent relayers in a blockchain environment. By integrating smart contract cores, application management contracts, and relayer nodes, the BRN ensures an efficient, reliable, and robust relay of transactions across various applications. The system cleverly addresses integration complexities, peer competition, and transaction management with a combination of off-chain and on-chain mechanisms. Moreover, it introduces mechanisms to guarantee the liveness of relayers while maintaining system performance and fairness. Features like âjail timeâ for non-compliant relayers ensure the overall networkâs health. The BRNâs design, which includes transaction batching and off-chain verifications, is inherently efficient and holds the promise of enhancing the utility of blockchain applications.