Relayers Network: Architecture and Operations

Overview

Symbiosis Relayers Network is a blockchain-agnostic, P2P network consisting of registered relayer nodes. It facilitates the secure and efficient transmission of data between supported blockchain networks, ensuring data integrity and resilience against potential attacks through various technical approaches and crypto-economic incentive mechanisms.

In this article we take a closer look at the components of the relayers ecosystem, their roles, and how they interact to facilitate cross-chain operations within the Symbiosis protocol.

Relayers Ecosystem

The components of the relayers ecosystem (Scheme 1) can be grouped into two main categories based on their application:

1. Cross-Chain Operation Processing

2. Relayers Network Organization and Coordination

Scheme 1. Components of the Symbiosis Relayers Ecosystem

Cross-Chain Operation Processing

At the heart of the Symbiosis protocol are the Core Smart Contracts (1), which implement the on-chain logic for cross-chain operations. These smart contracts are deployed across all blockchain networks supported by Symbiosis and are fine-tuned to handle requests specific to each network. When the smart contracts process a request, they generate events called Oracle requests. These events contain all the necessary data to execute the next steps of cross-chain operations on other chains and are key triggers for the relayers’ activity.

Relayers of the Symbiosis Relayers Network (2) continuously monitor new blocks on all supported blockchains, searching for Oracle requests created by the Core Smart Contracts. Once relayers detect a request, they validate the event, compose calldata with the instructions from the request, sign it, and then send it to the appropriate blockchain. In a nutshell, this is how instructions for cross-chain operations are transmitted from network to network.

It’s worth mentioning two microservices that relayers use when validating, and sending signed calldata with instructions for processing operations across blockchains: Advisor (3) and Broadcaster (4):

• Advisor (5): This microservice is used to fetch gas prices on the blockchains supported by Symbiosis, ensuring that transactions will be processed.

• Broadcaster (6): This microservice sends transactions with calldata signed by relayers to the respective blockchains.

Note on Microservices Design:

Some of the relayer’s functionalities were isolated into the Advisor and Broadcaster microservices to accelerate software development and minimize potential issues caused by the interaction of various components. These microservices cannot modify transaction data and do not have access to the user's or node runner's funds at any time.

However, it’s worth mentioning that, despite being simple, secure, and reliable, these microservices are currently centralized components. In the future, we may explore decentralized alternatives, such as:

1. Running multiple instances of each microservice type and delegating them to microservice runners for a fee.

2. Merging the microservice functions back into the relayer’s software.

3. Running the microservices as a separate decentralized service on a group of relayers.

With the process of cross-chain operations clarified, let’s move on to the structure and organization of the Symbiosis Relayers Network. How does a decentralized network coordinate and execute complex collective actions?

Relayers Network Organization and Coordination

The Symbiosis Relayers Network consists of independent relayer nodes, each running relayer software and registered in the Symbiosis PoS Staking Contracts (5). These contracts store information required to verify and authorize relayer nodes to participate in relaying operations and provide staking and rewards functionality.

Important: Nodes running the relayer software but not registered in the Symbiosis PoS Staking Contracts cannot participate in relaying operations and are not recognized as relayer nodes or as part of the Relayers Network.

Another critical component of the Relayers Ecosystem is the Relayers On-Chain Config Contract (6). This contract contains configuration data required for relayer collaboration, such as: the current size of the MPC group, the actual address of the Symbiosis PoS Staking Contracts, and other essential parameters.

Each relayer regularly queries the On-Chain Config Contract for updates to ensure alignment with the latest network configuration.

Additionally, relayer nodes registered in the PoS Staking Contracts can optionally register in the Symbiotic Staking Contract (7). This registration does not require additional staking. Instead, specific amounts of assets are allocated to each Symbiotic Operator (an entity registered in the Symbiotic Staking Contract) within Symbiotic Vault Contracts (8).

The stake provided in the Symbiosis PoS Staking Contracts and the assets allocated in the Symbiotic Vaults are both considered when selecting the MPC group (see Relayers Network Organisation).

As a result, the Symbiosis Relayers Network operates as a blockchain-agnostic, P2P network of registered relayer nodes. It facilitates the secure and efficient transmission of data between supported blockchain networks, ensuring data integrity and resilience against potential attacks through various technical approaches and crypto-economic incentive mechanisms.

Functions of the Symbiosis Relayers Network

The Symbiosis Relayers Network performs the following key functions:

1. Connecting to the Relayers Network: This involves initializing and connecting relayer nodes to the network, enabling them to participate in relaying operations.

2. Data Transfer between Blockchains: Facilitates the processing of cross-chain operations, ensuring secure and reliable data transmission across supported networks.

3. Epoch Change: During this process, a new MPC (Multi-Party Computation) group is selected, and a new MPC key is generated, ensuring continuous and decentralized network operation.

Before we continue, we should emphasize three two points:

1. Important: Multisig Symbiosis PoS Staking, On-chain Configuration and some of the Core contracts have functionality that allows the owner of the contracts to change the state of the contracts. The owner role is assigned to the address of the Multisig contract. Symbiosis administrators can only change the states of the contracts using the Multisig. This significantly reduces the impact of lost or compromised private keys and the human factor.

2. Important: RPC consensus Each relayer in the Relayers Network parses blocks from all blockchains supported by the Symbiosis protocol, looking for specific events emitted by Symbiosis contracts. There are two ways to trust to the source of the blocks and events:

   1. Full nodes: a node runner supports full nodes for all supported blockchains. In this case, the relayer node gets information about blocks and events from a trusted source.

   2. RPC consensus: a node runner cannot afford to support full nodes for all blockchains. In this case, the relayer node uses multiple RPCs per blockchain. And the relayer considers an event valid if it receives information about the event from at least 2 RPCs (the RPC consensus may differ from this model for blockchains that have problems with RPCs).

Relayers Network Organisation

The Symbiosis Relayers Network is divided into specific groups, each with distinct roles and responsibilities. The groups are illustrated in Scheme 2 below.

Scheme 2. The Relayers Network divided by groups.

Groups:

1. The Symbiosis Relayers Network comprises all relayer nodes registered in the Symbiosis PoS Staking Contracts. The size of the network is defined in these contracts.

2. The Bootstrap Group includes relayer nodes responsible for providing information about the relayer nodes currently connected to the Symbiosis Relayers Network. By default, the relayer software includes a configuration file listing bootstrapping nodes. Newly joining relayer nodes use this information to connect to the network. Any relayer node connected to the network can function as a bootstrapping relayer node.

3. The MPC Group is the active group for the current epoch, defined by an algorithm executed on each relayer node at the start of the epoch. Its responsibilities include:

   1. Validating and signing calldata: Processing Oracle requests emitted by Core contracts and routing the signed calldata to appropriate blockchains. A valid signature requires at least 2/3 of the MPC Group members.

   2. Generating and storing an MPC key: Each relayer node in the MPC Group holds a fragment of the key.

   3. Updating the MPC address: Replacing the MPC address of the previous epoch stored in the Core Contracts with a new one.

4. The Veto Group includes trusted relayer nodes that play a critical role in ensuring transaction security:

   • Full participation required: Every member of the Veto Group must participate in generating a valid signature. If even one member does not sign, the signature is invalid, and the Symbiosis Protocol halts processing of the associated calldata.

   • Veto by inaction: Instead of explicitly blocking transactions, the group vetoes suspicious transactions by abstaining from signing them.

   Currently, trusted relayer nodes are flagged in the Symbiosis PoS Staking Contracts by the Symbiosis sysadmins. In the future, the Relayers Network plans to decentralize the process of setting the Veto Group.

Relayers Network’s Functions

Connecting to the Relayers Network

When connecting to the Relayers Network (while starting or reconnecting), a relayer node connects to the bootstrapping nodes listed in its configuration file.

The relayer node that received the connect request identifies the connecting relayer node:

• Verifies that the address of the connecting relayer is in the Staking contract and that the relayer is not blocked,

• Obtains confirmation that the connecting relayer node has a private key that matches the address.

Once a relayer has authenticated a new connecting relayer node, the relayer:

• Broadcasts the information about that node to the Relayers Network,

• Sends the list of active connections to the connecting relayer node. The connecting relayer node establishes secure connections with all currently running relayer nodes.

All relayer nodes, after authentication, maintain active connections with each other over encrypted channels.

For more information about the keys used by a relayer node, please refer to Symbiosis Relayer.

Data Transfer between Blockchains

In fact, this is the essential function for which the Relayers Network exists: to transfer a message that contains instructions for a cross-chain operation from one blockchain to another.

An instance of the BridgeV2 contract is deployed on each blockchain supported by the Symbiosis protocol. The BridgeV2 contract issues an OracleRequest event when there is a need to send data about a cross-chain operation to another blockchain.

For more information about what happens on-chain during cross-chain operations, please refer to Symbiosis Routing Contracts. In this document, we focus on the Relayers Network.

Each relayer in the Relayers Network parses blocks from all blockchains supported by the Symbiosis protocol looking for OracleRequest events issued by the BridgeV2 contracts.

Each OracleRequest event has calldata consisting of:

• The destination network information (the network ID and the BridgeV2 contract address on that blockchain),

• Instructions for Symbiosis contracts on the destination blockchain.

Relayers should take the calldata, validate, sign, and send it according to the information from the calldata (Scheme 3 below).

Scheme 3. Data transfer routine.

1. The BridgeV2 contract on Blockchain A emits an OracleRequestevent.

2. Each relayer of the Relayers Network discover the OracleRequestevent.

3. The leader of the MPC group is the relayer with the largest stake in the group.

4. The leader checks the sufficiency of the approved fee from the OracleRequestevent with Advisor. For the explanation of fees for cross-chain operations, please refer to Symbiosis & Fees.

5. Relayers use the Hierarchical Threshold Signature Scheme (HTSS) to create TSS signatures. The leader initiates the generation of the TSS signature for the calldata from the OracleRequest event within the MPC group. Each relayer in the MPC group validates the calldata, signs it with its MPC key, and sends it back to the leader.

6. The leader collects signatures to complete the TSS signature and sends the signed calldata to Broadcaster.

7. Broadcaster fetches the optimal gas price from Advisor.

8. Broadcaster signs a transaction containing the signed calldata and sends the transaction to an appropriate blockchain.

The use of the Hierarchical Threshold Signature Scheme (HTSS) ensures that all members of the veto group participate in the creation of the TSS signatures. 2/3 of the MPC group is sufficient to create a valid signature.

Epoch Change

An epoch is a period of time during which relayrs use one MPC key. The epoch duration is 24 hours in normal operation. The entire epoch change process takes no more than 1 minute.

The epoch change process can be divided into four stages:

1. Initiating the epoch change.

2. Epoch change preparation. This stage includes:

   1. Formation of a new MPC group,

   2. Generation of a new MPC key,

   3. Approval of the epoch change by holders of 2/3 of the total stake.

3. Epoch change in the Staking contract.

4. MPC address change in the BridgeV2 contracts.

Scheme 4 shows Steps 1-3, and Scheme 7 shows Step 4.

Scheme 4. Epoch change routine.

1. Epoch Change Initiation

Each relayer in the Relayers Network parses blocks from S-chain looking for the events issued by the Staking contract.

The PrepareEpochChange event generated by the Staking contract initiates the relayers to change the current epoch.

Currently, initiating an epoch change is the responsibility of the Symbiosis sysadmins. In the future, however, the Relayers Network will initiate epoch changes in a decentralized manner.

Each relayer should discover the PrepareEpochChange event. After confirming a PrepareEpochChange event, each relayer determines a new RPC group (see next section: Epoch Change Preparation).

2. Epoch Change Preparation

All relayers (except blocked and offline relayers) in the Relayers Network participate in the epoch change procedure.

The epoch change Preparation consists of three stages:

1. New MPC group formation,

2. New MPC key generation,

3. Epoch change approval.

2.1. New MPC group formation

After confirming a PrepareEpochChange event, each relayer determines a new MPC group as follows:

1. Retrieve a list of all non-blocked relayers from the Staking contract. The list will include both online and offline relayers.

2. Shuffles the list using the seed from the PrepareEpochChange event. Since each relayer uses the same algorithm and the same input for the algorithm, the output is an ordered list that is the same for each relayer.

3. Determines the base of the new MPC group: the top 15 + 3 of the ordered list is the base for the new MPC group: 15 is the target MPC group size, and 3 is a reserve.

4. Determines the leader of the new MPC group: the leader is the relayer with the largest stake in the base for the new MPC group.

5. Since every relayer has the same ordered list, every relayer knows if it is at the top of the list or not. The leader goes through the base of the new MPC group and chooses the top 15 which are online for the leader. That’s the new MPC group.

1. This method allows any relayer (regardless of the size of its stake) to become a member of the MPC group and receive rewards. It also reduces the risk of malicious plotting within the Relayers Network.

2. All MPC groups always include all relayers of the veto group.

2.2. New MPC key generation (by the new MPC group)

All relayers of the new MPC group participate in generating private and public MPC keys. Each relayer obtains its segment of the private MPC key during the algorithm execution. The MPC address is written to the logs of each relayer of the new MPC group.

2.3. Approval of the epoch change (by the Relayers Network)

Once the new MPC key is ready, the Relayers Network should :

1. The leader of the new MPC group obtains the signature base for epoch change from the Staking contract, signs it with its own private key, and broadcasts it to the Relayers Network.

2. Each relayer verifies the signature base, signs it with its own private key, and sends it back to the leader of the new MPC group.

3. The leader of the new MPC group collects the signatures.

4. After collecting all responses, the leader of the new MPC group sends the collection to Broadcaster.

5. Broadcaster signs a transaction containing the data received from the leader and sends it to S-chain. The transaction calls the Staking contract to change the current epoch.

The epoch is changed when the following conditions are met:

• 2/3 of the total stake have signed the epoch change,

• All members of the veto group have signed the epoch change,

• All members of the new MPC group have signed the epoch change.

3. Epoch Сhange in the Staking contract

There are two ways to change the current epoch in the Staking contract:

1. The transaction with the necessary data prepared by relayers changes the epoch,

2. Symbiosis administrators manually change the current epoch using the data prepared by the new MPC group (the MPC address and the list of the relayers of the new MPC group). Such an action may be necessary in the following cases: it’s the zero epoch, or an issue occurs. For instance, many relayers are offline, and the Relayers Network cannot provide enough signatures to change the current epoch.

Once the epoch is changed in the Staking contract, the contract emits the EpochChanged event. This event signals the relayers to change the MPC address stored in the BridgeV2 contracts to the new one.

3.1. Reward distribution

Once the epoch is changed in the Staking contract, the rewards for the previous epoch are distributed among the following relayers:

1. Members of the MPC group of the changed epoch,

2. Those who signed the epoch change (this group is omitted if the epoch was changed by the Symbiosis team).

The distributed rewards will be added to the stake of each eligible relayer when the epoch changes again. The relayers can then claim rewards for withdrawal.

4. MPC Address Change in the BridgeV2 Contracts

Each relayer of the Relayers Network parses blocks from S-chain looking for the events issued by the Staking contract.

The EpochChanged event generated by the Staking contract initiates relayers to replace the MPC address stored in the BridgeV2 contracts with a new one (Scheme 5 below).

An instance of the BridgeV2 contract is deployed on each blockchain supported by the Symbiosis protocol. Each BridgeV2 contract stores an MPC address and only processes requests signed by the corresponding MPC key.

Relayers track information about MPC addresses stored in each BridgeV2 contract and sign calldata with an appropriate MPC key for every blockchain. The Relayers Network always strives to update MPC addresses stored in the BridgeV2 contracts to the MPC address stored in the Staking contract.

Scheme 5. MPC address change in the BridgeV2 contract.

1. The Staking contract emits an EpochChanged event.

2. Each relayer discovers the EpochChanged event.

3. The leader of the MPC group is the relayer with the largest stake in the group.

4. The leader initiates the generation of the TSS signature for the calldata to change the MPC address on the BridgeV2 contract within the MPC group. Each relayer in the MPC group validates the calldata, signs it with its MPC key, and sends it back to the leader. Relayers use the Hierarchical Threshold Signature Scheme (HTSS) to create TSS signatures.

5. The leader collects the signatures to complete the TSS signature and sends the signed calldata to Broadcaster.

6. Broadcaster signs a transaction containing the signed calldata and sends the transaction to an appropriate blockchain.

7. Once the transaction is mined, the MPC address in the contract is changed and the contract emits the LogChangeMPC event.

8. Each relayer of the Relayers Network discovers the LogChangeMPC event and locally updates the data for the blockchain. In this way, each relayer knows which MPC key should be used for each blockchain.

The BridgeV2 contracts on different blockchains may have MPC addresses corresponding to different epochs. The MPC group with an MPC key corresponding to the MPC address stored in the BridgeV2 contract will replace the address with a new one in that contract.

The Hierarchical Threshold Signature Scheme (HTSS) ensures that all members of the veto group participate in the creation of the TSS signatures. 2/3 of the MPC group is sufficient to create a valid signature.

In some cases, Symbiosis administrators need to manually change the MPC address stored in the BridgeV2 contract manually. For instance, a blockchain has been offline for a few days, several epochs have passed, and the MPC group with the corresponding MPC key cannot provide a quorum to create a valid TSS signature to change the MPC address.