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.

Relayer nodes 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 relayer nodes 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 relayer nodes 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 Epoch Change).

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.

Network Structure and Role Distribution

To effectively carry out its functions, the Symbiosis Relayers Network is structured into distinct groups, each with a specific role in maintaining network functionality and security. These groups ensure efficient coordination and reliable execution of cross-chain operations. The organization of these groups is illustrated in Scheme 2 below

Scheme 2. The Relayers Network divided by groups.

Where:

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

2. The Bootstrap Group is responsible for providing connection information to new relayer nodes joining the 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 currently connected to the network can function as a bootstrapping node.

3. The MPC Group (Multi-Party Computation Group) is the active group for the current epoch, selected by an algorithm executed on each relayer node at the start of an epoch. It is responsible for:

   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 of 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 abstains, the signature is invalid, and the Symbiosis Protocol halts processing of the associated calldata.

   • Veto by Inaction: Instead of explicitly blocking transactions, the Veto Group members do not sign transactions they consider suspicious. This prevents unauthorized or potentially malicious transactions from being executed. Governance of the Veto Group: Currently, trusted relayer nodes are manually flagged in the Symbiosis PoS Staking Contracts by Symbiosis sysadmins. In the future, the Relayers Network aims to transition to a decentralized method of setting the Veto Group.

Functions of the Symbiosis Relayers Network

The Symbiosis Relayers Network performs the three key functions:

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

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

3. Epoch Change: At the start of a new epoch, a new MPC (Multi-Party Computation) group is selected, and a new MPC key is generated, ensuring decentralized and continuous network operation.

Important Considerations

Before continuing, two key points should be highlighted:

1. Multisig Protection

Symbiosis PoS Staking Contracts, On-Chain Configuration, and Core Contracts have functionalities that allow their state to be modified. These changes can only be made by the contract owner, which is assigned to a Multisig contract. Why this matters: Symbiosis administrators can only update contract states via Multisig, reducing the risks associated with lost or compromised private keys and minimizing human error.

2. RPC Consensus Mechanism

Each relayer in the Relayers Network monitors blocks across all supported blockchains, searching for specific events emitted by Symbiosis contracts.

There are two ways a relayer node can validate block and event data:

• Full Nodes: the relayer node runner supports full nodes for all supported blockchains. In this case, the relayer node retrieves data from trusted, self-operated nodes.

• RPC Consensus: if a relayer node runner cannot support full nodes for all blockchains, the relayer node relays on multiple RPC endpoints per blockchain. An event is considered valid if it is confirmed by at least two independent RPC sources. Note: The RPC consensus model may vary for blockchains that experience RPC-related issues.

Connecting to the Relayers Network

When a relayer node starts or reconnects to the Relayers Network, it first connects to the bootstrapping nodes listed in its configuration file.

Authentication Process

The relayer node receiving the connection request verifies the identity of the connecting relayer node by:

1. Checking Registration Status:

   • Ensuring that the relayer node's address is present in the Symbiosis PoS Staking Contracts.

   • Verifying that the relayer node is not blocked.

2. Verifying Ownership:

   • Confirming that the connecting relayer node possesses a private key corresponding to its registered address.

If any of these checks fail, the connection request is rejected. In the case of suspicious or repeated failed attempts, additional security measures may be triggered.

Establishing Network Connectivity

Once a relayer node is successfully authenticated:

1. The verifying relayer broadcasts information about the newly connected node to the Relayers Network.

2. The verifying relayer sends a list of active connections to the new relayer node.

3. The new relayer establishes secure connections with all currently active relayer nodes.

Maintaining Secure Connections

After authentication, all relayer nodes maintain active, encrypted connections with each other to ensure secure communication.

For more details on the key management process for relayer nodes, please refer to Symbiosis Relayer Node

Cross-Chain Data Transfer

For details on on-chain processes during cross-chain operations, please refer to Symbiosis Routing Contracts. This document focuses specifically on the role of the Relayers Network.

The primary function of the Symbiosis Relayers Network is fast and secure cross-chain data transfer, ensuring that messages containing instructions for cross-chain operations are reliably transmitted between blockchains without modification.

Core Smart Contracts handle the on-chain logic for cross-chain operations and are deployed on all supported blockchains. When processing a request, they generate an OracleRequest — an event containing the data needed for the next steps. These events trigger The Relayers Network activity for cross-data transfer.

Monitoring OracleRequest Events

Relayer nodes store information about supported blockchain networks and contract addresses in their configuration files.

Each relayer node in the Symbiosis Relayers Network continuously monitors blocks across all supported blockchains, searching for OracleRequest events issued by specific contracts.

Each OracleRequest event includes calldata that contains:

• Destination network information: The target network ID and the contract address on that blockchain.

• Execution instructions: Instructions for the Symbiosis Core Contracts on the destination blockchain.

Processing OracleRequest Events

Once an OracleRequest event is detected:

1. Each relayer node validates it to ensure authenticity and integrity.

2. The MPC group signs the calldata, ensuring its validity.

3. The signed calldata is promptly transmitted to the appropriate blockchain according to the event details.

See Scheme 3 below for an illustration of this process.

Scheme 3. Data transfer routine.

1. The Core Contracts on Blockchain A emits an OracleRequest event.

2. Each relayer in the Relayers Network detects and validates the OracleRequest event.

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

4. The leader verifies that the approved fee specified in the OracleRequest event is sufficient by querying Advisor. For more details on fees for cross-chain operations, see Symbiosis & Fees

5. TSS Signature Generation:

   1. The leader initiates the TSS signature generation for the calldata from the OracleRequest event within the MPC group.

   2. Each relayer in the MPC group validates the calldata, signs it with its MPC key, and sends the signed data back to the lider.

6. The leader collects the 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 the destination 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.

Security & Consensus Mechanism

• The Hierarchical Threshold Signature Scheme (HTSS) ensures that all Veto group members participate in the TSS signature creation.

• A valid TSS signature requires approval from at least 2/3 of the MPC group.

Epoch Change

An epoch is a fixed time period during which a selected MPC group handles cross-chain data transfer using a single MPC key. Under normal operation, each epoch lasts 24 hours, and the epoch change process takes less than a minute.

The epoch change triggers:

• Reorganization of the Relayers Network and MPC key generation.

• Distribution of rewards for the previous epoch.

Epoch Change Process

Scheme 4. Four stages of epoch change process.

The process consists of four key stages:

1. Epoch change initialization.

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 at least 2/3 of the total stake.

3. Epoch change in the PoS Staking Contracts, including rewards distribution.

4. MPC address update in the Core Contracts on all supported chains.

1. Epoch Change Initialization

The PoS Staking contracts have a method that solely emits the PrepareEpochChange event without modifying the contract’s state. This event acts as a trigger for the epoch transition.

An epoch change can be initiated in one of two ways:

• By the Relayers Network, which collectively signs a transaction to call the method.

• By the Symbiosis team, manually invoking the method.

Currently, initiating an epoch change is the responsibility of the Symbiosis team. However, in the future, the Relayers Network will transition to a decentralized process for initiating epoch changes.

Each relayer node continuously monitors blockchain blocks, searching for events emitted by the PoS Staking contract.

• When the PrepareEpochChange event is issued by the PoS Staking contracts, each relayer node detects and validates this event before proceeding with the epoch transition.

• Upon confirming a PrepareEpochChange event, each relayer determines a new RPC group using a predefined algorithm (see next section: Epoch Change Preparation).

2. Epoch Change Preparation

All active relayer nodes (excluding blocked and offline nodes) participate in the epoch change preparation, which 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. Fetch a list of all non-blocked relayer nodes from the PoS Staking Contracts (includes both online and offline nodes).

2. Sort the List:

   1. All Veto relayer nodes come first,

   2. Remaining relayer nodes are ordered by stake, combining PoS Staking and Symbiotic delegated amounts.

   ⇒ Since every relayer runs the same algorithm on the same data, the output is a consistently ordered list across all relayer nodes.

3. Select the Base MPC Group: the top 18 relayer nodes in the ordered list form the base group (15 primary + 3 reserve).

4. Determines the Group Leader: the relayer node with the largest stake in the base group is selected as the group leader.

5. Finalize the New MPC Group: the leader verifies which of the top 15 nodes are online. The first 15 online relayers form the new MPC group. The maximum MPC group size is 15, but the actual size is defined in the PoS Staking Contracts. Relayer nodes retrieve this value from the PoS Staking Contracts and use it when selecting the new MPC group.

2.2. New MPC Key Generation (by the New MPC Group)

All relayer nodes in the new MPC group participate in generating an MPC key pair. As part of the algorithm's execution, each relayer node in the group derives a segment of the private MPC key.

Upon completion, each relayer node logs the MPC address, which is derived from the public MPC key.

2.3. Approval of the Epoch Change (by the Relayers Network)

Once the new MPC key is generated, the Relayers Network must approve the epoch change through the following process:

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

2. Each relayer verifies the leader’s signature and the signature base. If valid, the relayer signs the base with its private key and sends it back to the leader.

3. After collecting all responses, the leader sends the collection to Broadcaster.

4. Broadcaster signs a transaction containing the data received from the leader and sends it to the PoS Host Chain.

3. Epoch Change in the PoS Staking Contracts

The PoS Staking Contracts allow epoch changes to be executed in two ways:

(1) Automatic Epoch Change by the Relayers Network

The Relayers Network submits a transaction containing the necessary data to change the epoch (see the section above: 2.3. Approval of the Epoch Change (by the Relayers Network).

The epoch change is finalized when the following conditions are met:

• At least 2/3 of the total stake have signed.

• All veto group members have signed.

• All new MPC group members have signed.

If all conditions are met, the PoS Staking Contracts update the current MPC address, the MPC group, and emit the EpochChanged event.

(2) Manual Epoch Change by Symbiosis Administrators

Symbiosis administrators can manually update the epoch using the MPC address and MPC group data prepared by the new MPC group.

This manual process may be required in the following cases:

• Zero epoch initialization.

• Relayers Network failure (e.g., an insufficient number of online relayer nodes to sign the epoch change).

Once executed, the PoS Staking Contracts update the current MPC address, the MPC group, and emit the EpochChanged event.

3.1. Reward Distribution

Once the epoch is updated in the PoS Staking Contracts, rewards for the previous epoch are distributed among:

• Relayer nodes who signed the previous epoch change (this is omitted if the previous epoch was change manually by the Symbiosis team).

Rewards are added to each eligible relayer node’s stake (the PoS Staking Contracts) and become available for claim after the next epoch change.

4. MPC Address Update in Core Contracts

The Symbiosis Core Contracts, deployed across all supported blockchains, store an MPC address and only process operations signed by the corresponding MPC key.

Relayer nodes track MPC addresses stored in Core Contracts and sign calldata using the appropriate MPC key for each blockchain.

To ensure security and functionality, the MPC address stored in Core Contracts must remain in sync with the PoS Staking Contracts.

MPC address updates can be performed in two ways:

(1) Automatic Epoch Change by MPC Groups

When the PoS Staking Contracts emit an EpochChanged event, it triggers relayer nodes to begin updating MPC addresses across all supported networks.

The process follows these steps:

1. The MPC group holding the MPC key corresponding to the Core Contract's stored address is responsible for updating it.

2. The MPC group composes, signs and submits a transaction to update the MPC address.

3. The update is finalized when:

   • At least 2/3 of the MPC group have signed.

   • All Veto group members have signed.

Once these conditions are met:

• The Core Contracts update the current MPC address and emit a LogChangeMPC event.

• Each relayer node detects this event and updates its locally stored information.

(2) Manual Epoch Change by Symbiosis Administrators

In some cases, Symbiosis administrators may need to manually update the MPC address in Core Contracts on some or all supported blockchains.

This manual process may be required when:

• The Relayers Network is unable to update the MPC address due to an insufficient number of online nodes in the corresponding MPC group. For example, if a blockchain has been offline for several days and multiple epochs have passed, the MPC group holding the corresponding key may no longer have quorum to generate a valid TSS signature for the update.

Once executed:

• The Core Contracts update the current MPC address and emit a LogChangeMPC event.

• Each relayer node detects this event and updates its locally stored information.

Scheme 5. MPC address change in the BridgeV2 contract.

1. The PoS Staking Contracts emit an EpochChanged event.

2. Each relayer node in the Relayers Network detects and validates the EpochChanged event.

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

4. TSS Signature Generation:

   1. The leader initiates the TSS signature generation for the calldata needed to update the MPC address in the Core Contracts.

   2. Each relayer in the MPC group validates the calldata, signs it with its MPC key, and sends the signed data back to the lider.

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 the appropriate blockchain.

7. Once the transaction is mined, the Core Contracts update the MPC address and emit a LogChangeMPC event.

8. Each relayer node in the Relayers Network detects and validates the LogChangeMPC event and updates its locally stored data for that blockchain. This ensures that each relayer node always knows which MPC key should be used for each blockchain.

Security & Consensus Mechanism

• The Hierarchical Threshold Signature Scheme (HTSS) ensures that all Veto group members participate in the TSS signature creation.

• A valid TSS signature requires approval from at least 2/3 of the MPC group.