🟦Symbiosis Relayers Network

Important definitions and a bird's-eye view of the Relayers Ecosystem: the off-chain part of the Symbiosis protocol that transfers information across blockchains.

Introducing the Symbiosis Relayers Network

The Symbiosis Relayers Network is a peer-to-peer (P2P) network designed to enable fast, accurate, and secure transmission of information for cross-chain operations. As the off-chain component of the Symbiosis protocol, the network plays a crucial role in ensuring smooth and secure communication across blockchains.

The primary function of the Relayers Network is to transfer messages containing instructions for cross-chain operations between blockchains. To facilitate this process, each blockchain supported by the Symbiosis protocol has a set of smart contracts deployed. When a cross-chain operation is initiated, the contracts issue an event, which the relayers in the network monitor and process.

In this section, we focus on how the relayers network works. An explanation of the Symbiosis protocol's on-chain part (smart contracts) is available in the section Cross-chain liquidity engine.

Definitions

There are several definitions that are important for further explanation.

Relayer

A relayer is a node with special software running on it with two requirements for that entity:

1. The node and staker addresses are registered in the Staking contract. The node address corresponds to the node’s private key; the staker address is used to manage staked SIS tokens and withdraw rewards. All addresses in the Staking contract are unique: one staker address can only be associated with one node address and vice versa.

2. A stake of a certain size is deposited from the staker address into the Staking contract for that entity.

If the requirements are met, the node can participate in the relayers network, and the staker associated with that node can receive rewards for the node’s work. From now on, we will refer to such an entity as (a) relayer.

Node runner

A node runner is an individual or an organization that provides SIS tokens for staking, runs a relayer, and receives rewards for staking and bridging blockchains.

S-chain

S-chain is a service blockchain for the Symbiosis protocol in general. The Staking and On-chain configuration contracts that are critical to the relayers network are deployed on this blockchain.

Epoch

An epoch is a period of time during which relays use an MPC key. The duration of an epoch is 24 hours during normal operation.

MPC key

A Multi-Party Computation (MPC) key is a private key that is divided among multiple parties to create a signature without revealing the key fragments to each other.

MPC address

An MPC address is an address derived from the public key corresponding to an MPC key.

Relayers Ecosystem

Scheme 1. Relayers Ecosystem.

The relayers ecosystem consists of the following parts (Scheme 1):

1. The Symbiosis relayers network is a P2P network where each peer is a node running special software. The node information is registered in the Staking contract (2). Each relayer receives rewards for participating in the network operation if certain conditions are met. The purpose of the Symbiosis relayers network is the fast, accurate, and secure transfer of information about cross-chain operations between blockchains supported by the Symbiosis protocol.

2. The On-chain configuration contract contains some information important for the collaboration of relayers. For instance, a number of nodes in the MPC group, an actual address of the Staking contract, etc. Each relayer checks the contract for updates when an epoch changes.

3. The Staking contract contains information about relayers (addresses, status, stake, reward amounts, etc.), epochs, MPC addresses, etc. The Staking contract is essential for the operation of the relayers network.

4. The BridgeV2 contract connects the off-chain and on-chain parts of the Symbiosis protocol: the relayers network and Symbiosis contracts. An instance of the BridgeV2 contract is deployed on each blockchain supported by Symbiosis.

   Please refer to the document Symbiosis Routing Contracts for more information about the workflow of the core Symbiosis contracts.

5. Microservice Advisor estimates gas prices on the blockchains supported by Symbiosis. Please refer to Advisor for more information about Advisor.
6. Microservice Broadcaster sends transactions with calldata signed by relayers to blockchains.

7. WebApp for Node Runners is a web-based application provided by Symbiosis that helps node runners to interact with the Staking contract: register their relayers and manage stakes and rewards.

Before we continue, we should emphasize three important points:

1. Important: Multisig Contracts Staking, BridgeV2, and On-chain configuration have functionality that allows the owner of the contracts to change the states 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 with multisig. That significantly reduces the impact of loss or compromise of private keys and the human factor.

2. Important: Microservices We have isolated some of the relayer’s functionalities into Advisor and Broadcaster microservices to speed up software development while minimizing potential problems associated with the interaction of different components of the system. The microservices cannot modify transaction data and do not have any access to the user's or node runner's funds at any time. However, no matter how simple, secure, and reliable the microservices are, they remain centralized elements. Therefore, in the future, we may consider moving to a decentralized solution. For instance:

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

   2. Merging the functions of the microservices back into the relayer’s software.

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

3. 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 the Staking and BridgeV2 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

The Symbiosis relayers network is a P2P network with built-in crypto-economic incentive mechanisms. The relayers network is an off-chain part of the Symbiosis protocol. The main purpose of the network is to provide fast, accurate, and secure transmission of information about cross-chain operations performed via the Symbiosis protocol.

During operation, the relayers network is divided into the groups shown in Scheme 2 below.

Scheme 2. The relayers network divided by groups.

1. The Symbiosis relayers network is a set of all relayers (see the definition of a relayer). The network is built as follows:

   1. Symbiosis admins define the set size (the maximum number of relayers) in the Staking contract,

   2. Node runners stake and register their nodes in the Staking contract.

2. The Bootstrap group includes relayers that provide information about relayers currently connected to the Symbiosis relayers network to newly joining relayers. Although the relayer software comes with a configuration file that lists default bootstrapping nodes, any relayer node connected to the relayers network can be used as a bootstrapping relayer.

3. The MPC Group is an active group of the current epoch. The group is defined by an algorithm that runs on each relayer at the beginning of the epoch. Its functions include:

   1. Validating and signing the calldata form Oracle requests emitted by the BridgeV2 contracts and routing the signed calldata to appropriate blockchains. 2/3 of the MPC group is enough to create a valid signature.

   2. Generating and storing an MPC key (each relayer of the MPC group keeps a fragment of the key).

   3. Replacing the MPC address of the previous epoch stored in the BridgeV2 contracts with a new one.

4. The Veto Group includes trusted relayers. All relays of this group must participate in creating every signature generated by the MPC group. If at least one signature of a veto group member is missing, the signature is invalid, and the Symbiosis protocol does not proceed calldata with such a signature. Thus, the Veto Group itself does not suppress anything by a separate ban; instead, the relayers of this group do not sign transactions that look suspicious. That is, they veto not by action but by inaction.

   A special flag set for a relayer in the Staking contract indicates a trusted relayer. Currently, the setting the veto group is the responsibility of the Symbiosis sysadmins. In the future, however, the relayers network will set the veto group in a decentralized manner.

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 Gas Fees for Cross-chain Operations via Symbiosis.

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.