BRN: Transaction Allocation Mechanism

Biconomy Relayer Network (BRN)
1

BRN: Transaction Allocation Mechanism

In a closed environment vis-a-vis a centralized system, a relayer performs its job of relaying transactions, and the system is trusted to ensure that:

  • the transactions are not tampered with or censored by any individual relayer.
  • the relayers send those transactions in the most optimal manner (gas fee optimized).
  • individual relayers do not compete for their transactions to be included in a block, which otherwise will result in losses and inefficiencies in the system.

On the contrary, in a decentralized system, all relayers will have access to a shared pool of transactions. The relayers store transactions broadcast to the network in their local memory (i.e., a shared record of non-submitted transactions, aka the Mempool). The decentralized network introduces a small fee incentive for the relayer’s work. In such a scenario, a relayer can send a transaction already sent by another relayer with a higher gas price; this process can repeat without end, which leads to competition among relayers, likely generating losses in the form of failed transactions. This also makes the network vulnerable to various types of attacks in which a malicious user generates many transactions, sends them to the network, and at the same time proceeds to execute them, causing losses in failed transactions to the relayers in the network.

To avoid this, it is necessary to devise a mechanism that allocates transactions in an organized manner, minimizing or, to some extent eliminating the risk of two or several relayers submitting the same transaction. Furthermore, transactions should be funneled through a mechanism that prevents malicious users from submitting the same transaction through alternative paths, as described above.

System Diagram

General diagram
General diagram2214Ă—1434 191 KB

Apps: web3 apps that use Biconomy’s technology for meta transactions, account abstraction, etc. For simplicity, we refer to all types of transactions submitted by apps as meta transactions.

Relayer network: A network of computers that shares a register of transactions submitted by the apps. Relayers must bond $BICO tokens to join the network and receive delegated stake (i.e., total stake). Their share of the network stake determines the number of transactions allocated to them. That is, a relayer with 10% of the total stake has a 10% chance of being selected to relay meta transactions on every selection round.

Intermediary contract: Smart contract that sets and enforces transaction allocation, ensuring that all the network members respect the system’s rules.

Apps submit meta transactions to the relayer network using the Biconomy SDK through multiple endpoints (each relayer provides an endpoint for apps to submit transactions). Via a P2P network, relayers share information about meta transactions pending to be executed and, in general, about the status of the network. A smart contract passively manages transaction allocation. Relayers query the contract to determine whether transactions have been allocated to them and if that is the case, they proceed to batch and submit the transactions. The system guarantees that no other relayer gets assigned the same transactions within a time window. Any relayer transaction that attempts to submit the same meta transaction will fail.

Transaction Allocation Mechanism

In a group of relayers R and a set of meta transactions T, transaction allocation is the process of allocating transactions to relayers such that each relayer’s allocation does not conflict with any other relayer in a particular time interval.

Let A(T,r_i) \subset T denote the transactions allotted to relayer r_i \in R. Then,

\forall (r_i,r_j)\in R\times R,r_i\neq r_j \implies A(T,r_i)\cap A(T,r_j)=\phi

This is achieved using a 2-step mechanism.

  1. Relayer sub-sampling: 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.

  2. Direct allocation: from the full set of pending meta transactions T, meta transactions are allocated to the selected relayers based on the hash of calldata, such that meta transactions are divided uniformly among the selected relayers r.

The process is described in the following diagram:

Allocation diagram
Allocation diagram2528Ă—700 61.3 KB

This means that for every N block, a new set is selected, and the available transactions are distributed among the selected nodes. The rationale for this 2-step procedure follows:

  1. Selecting multiple relayers for each window reduces the probability of halting the network due to relayers going offline—increasing the liveness of the network.
  2. Attempts to censor meta transactions are handled by re-allocating them at each time window, such that if a malicious relayer omits a transaction in an attempt to censor users, the same transaction will remain in the network’s Mempool and will be picked up by a different relayer in the next window.
  3. Direct allocation via the hash of the call data allows complying with the requirement that two or more relayers will not submit the same meta transaction.

Notice that the allocation mechanism was described as passive. This means that no additional transaction is required to assign meta transactions; instead, the allocation changes dynamically with parameters of the blockchain, such as block number and timestamp. Relayers query the intermediary smart contract to discover the current state of the network and get the list of transactions that they are allowed to submit for a particular time interval.

Commonly Asked Questions

What happens if a relayer has a set of transactions allocated and decides not to submit them to the blockchain?

Transactions in the Mempool of Biconomy’s relayer network are reassigned every N block (the length of a window in the system) in a probabilistic manner. This means that the same transactions will be in the following window submitted by another relayer if the currently assigned relayer fails to submit the transaction. While a relayer can be selected in two consecutive windows, the probability of being selected and to have the same transaction allocated is significantly low.

What happens if a relayer is offline?

Relayers should submit transactions that are assigned to them in the window. If they fail to follow the rules, they will be penalized by applying a penalty in their staked $BICO amount. This mechanism is fully decentralized. Relayers are incentivized to provide cryptographic proofs to penalize non-compliant participants on the network.

Will the network support delegation of $BICO?

Yes, $BICO holders can delegate tokens to any relayer and obtain rewards for supporting the network.

What type of transactions will be supported by the network?

The network is being designed to be as general as possible. Any service requiring a decentralized network can plug into Biconomy’s network and benefit from the decentralized network of relayers.

What blockchains will be supported?

The current design is extensible to all the EVM networks, and future work will also incorporate non-EVM networks. The first network to be supported will be Ethereum.

Conclusion

This post describes the allocation mechanism of Biconomy’s relayer network (BRN). The allocation system uses an intermediary contract to enforce transaction allocation without the need for achieving consensus among the relayers. Parameters of the blockchain are used to reallocate transactions in cases where relayers are offline or irresponsive, ensuring that transactions can not be censored. The general design extends the use of the relayer network to any use case requiring relaying transactions, including automation and cross-chain applications.

Certain aspects of the solution are not discussed in detail in this post, like how penalties would work, how the Mempool would look like, how rewards are split among delegators, etc. These will be touched upon individually in future posts.

Share your views on the mechanism and ask probing questions. We can together make the solution more robust.

2 Likes
2

This allocation mechanism based on a probabilistic methodology seems perfectly fit. Theorically, a « small » relayer with a low number of bonded tokens should still be able to relay transactions, which is great for decentralisation.

Quick questions on my side :
From a relayer perspective, I was wondering if each allocated transaction would generate the same amount of revenue (ie : the small fee charged for the relayer work). In other words, is it equivalent for them to provide a cross chain execution or a gasless service?

From the perspective of someone delegating its tokens to a relayer, what a penalty means in case of a relayer wrong-doing / going offline ?

Cheers,
David

1 Like
3

Hi David! Thanks for the question.

With respect to revenue/tx, it will be tx dependent. The network fee is structured as a percentage of total gas cost (gas units * gwei). So, for heavy computation at expensive gwei prices, the network fee will be more. We will be pushing out a post soon that describes in more detail the fee mechanism.

As for penalties, we are not planning to explicitly penalize delegator stake. We think we can incentivize good delegator habits through opportunity cost of lost fees for delegators staking with an underperforming node (i.e., nodes missing tx allocation and jail time). The aforementioned post will include some details around penalties, as well.

Trevor

3 Likes
4

Thanks - this is a comprehensive design and explains the mechanism well. I wanted to better understand delegations:

  1. What will be the revenue distribution between relayers and delegators?
  2. Can delegators choose the relayer to which their tokens will be delegated, and if yes, then a follow-up to @trevor_bico’s response - Will a relayer not have the incentive to delegate their $BICO to themselves rather than staking it to avoid all risks of slashing even in the case of underperformance?

Thanks,
Kratik

1 Like
5

Our thought is to allow some flexibility for nodes to define revenue sharing. The node can specify a separate sharing rate for BICO rewards and transaction premiums. Once a node has defined a sharing agreement, they would be locked into that rate for some defined period of time (i.e., 30 days).

Delegators can choose which node to delegate to. Nodes must bond 10k BICO in order to join the network. This amount can be penalized.

1 Like