bifrost-relayer.rs
What is bifrost-relayer.rs?
We recently introduced a Rust implementation of the CCCP-Relayer for the Bifrost Network. The new relayer has been reengineered to enhance overall performance and robustness across multiple blockchains. It retains the same functions as the Python version, processing cross-chain transactions and facilitating data transfers (e.g., feeding price information) from one blockchain to another.
The following section will guide you through the setup process about the Rust implementation of the Bifrost network's relayer.
Install Requirements
To initiate the bifrost-relayer
, certain dependencies must be manually installed. Both the executable binary file and the configuration YAML file are essential for all environments and operators.
First, install the latest bifrost-relayer
release binary. You can check the latest releases by going to our GitHub repository under the releases page.
In order to execute the binary, the permission of the file has to be updated.
Then, install the configuration YAML file. This file serves as an example for a quick start. Given the minor differences between Testnet and Mainnet environments, it's crucial to use the appropriate file for the corresponding network.
Configuration Setup
Next, the configuration YAML file contains certain parameters that the operator has to set. For instance, variables such as your relayer private key and each EVM provider's RPC endpoints depends to the operator itself, thus these values should be manually set.
You should prepare RPC endpoints for the following blockchain networks. There are two options for this: 1) operating your own blockchains nodes, or 2) utilizing services that offers RPC endpoints. You can find node providers on the links below. It’s crucial that each node must be archive-mode enabled.
Bifrost (Must be priorly self-operating and fully synced)
Configuration Templates
Configuration Parameters
The following table presents customizable parameters for the relayer. You can change each parameter according to your environment. However, we highly recommend to use the default values specified in the template except for fields that are not checked in the "Template Provided" column. Furthermore, "Template Provided" merely serves as an example, thus you must change the correct values for certain parameters (e.g., your private key).
Generally, for safety and to prevent unexpected system malfunctions, you should refrain from altering parameters that are included in the YAML file but not explicitly specified. If the network's self-monitoring mechanism detects a malfunction stemming from altered parameters, the offending relayer may be subject to slashing.
Using Systemd
For operators who prefer on using Systemd, you should make a configuration file for the Systemd execution environment. First, create a configuration file in the following directory.
An example of the configuration is provided below. The following parameters should be set regarding to your setup environment.
<DIRECTORY_WHERE_BIFROST_RELAYER_LOCATES>
: The absolute path to the directory where the installedbifrost-relayer
binary file locates.<PATH_TO_BIFROST_RELAYER>
: The absolute path to the installedbifrost-relayer
binary file.<PATH_TO_CONFIG_FILE>
: The absolute path to the installedconfig.testnet.yaml
orconfig.mainnet.yaml
. This parameter will be the the value for the CLI option,--chain
.
Run the Relayer Service
Now, the service can be started by executing the following commands. First, enable the service that will let it start automatically at every next system restart.
Then, start the Systemd service, executing instructions in the service’s configuration file, use the start
command as mentioned below.
And lastly, verify the service has successfully executed.
Check Logs
To check your running bifrost-relayer
service logs, execute the command below.
Once the service has successfully started, the initial logs will show up similar as below.
If the bootstrap configuration is enabled, it will then start to bootstrap historical events as below.
After the initial launch and the bootstrap process ends, the system will wait until each chain has reached the block confirmations specified in your configuration YAML file. It will then import every new block on every interval as below.
If your relayer has met every system logs mentioned above, this means that it has successfully been launched and has started to operate in a healthy state.
Upgrade Service
As the bifrost-relayer
is under continuous development, there will be instances when it becomes necessary to upgrade your relayer service. When such upgrades become available, relayer operators will be notified either through our community channels or via direct communication. Please note that some upgrades may be optional rather than mandatory.
First, remove or backup the previous bifrost-relayer
binary file.
Then, install the latest version of bifrost-relayer
into the same directory and update permissions. (In case of directory changes, the Systemd configuration file should be modified as well)
At last, restart the Systemd service.
Using Docker
For operators who prefer on using Docker, it must be pre-installed in your operating system. Once installed, you can proceed to the following steps.
To run the relayer as a Docker container, use the command as mentioned below.
<DIRECTORY_WHERE_CONFIG_FILE_LOCATES>
: The absolute path of the directory where the installedconfig.testnet.yaml
orconfig.mainnet.yaml
locates.<YOUR_CONFIG_FILE_NAME>
: The file name of the installed configuration YAML file.<YOUR_CONTAINER_NAME>
: Please set an explicit name for your relayer container.
Check Logs
To check your running bifrost-relayer
container logs, execute the command below.
Upgrade Docker Image
As the bifrost-relayer
is under continuous development, there will be instances when it becomes necessary to upgrade your relayer service. When such upgrades become available, relayer operators will be notified either through our community channels or via direct communication. Please note that some upgrades may be optional rather than mandatory.
First stop and remove your running relayer container.
Then, pull the latest bifrost-relayer
Docker image.
At last execute the following command below to start a new container.
Parameter Descriptions
system
System related parameters of the relayer.
-
-
system.private_key
The private key of the relayer.
"0x5fb92d6e98884f76de468fa3f6278f8807c48bebc13595d45af5bdc4da702133"
-
system.debug_mode
The flag that represents if the debug mode is enabled. If enabled, debug-level logs and sentry alerts will be enabled.
true
/ false
false
btc_provider
The parameters related to the Bitcoin chain provider.
-
-
btc_provider.id
The unique ID of the Bitcoin chain.
10000
(For Mainnet)10001
(For Testnet)
-
btc_provider.chain
The name of the Bitcoin chain.
"main"
(For Mainnet)"test"
(For Testnet)
-
btc_provider.provider
The RPC endpoint of the Bitcoin chain.
-
-
btc_provider.call_interval
The block synchronization interval in milliseconds. At every new interval, the system will synchronize every new block mined on the target chain.
10000
-
btc_provider.block_confirmations
The number of block confirmations required to synchronize a new block.
3
3
evm_providers
The parameters related to EVM chain providers.
-
-
evm_providers.id
The unique ID of the chain.
3068
-
evm_providers.name
The name of the chain.
"bifrost"
-
evm_providers.provider
The RPC endpoint of the node. If the node is running, or is expected to be operated on the same server with the relayer, then set this value to the provided example.
"http://127.0.0.1:9933"
-
evm_providers.call_interval
The block synchronization interval in milliseconds. At every new interval, the system will synchronize every new block mined on the target chain.
1500
-
evm_providers.block_confirmations
The number of block confirmations required to synchronize a new block.
5
-
evm_providers.is_relay_target
The flag which represents whether the system will participate in external-chain CCCP actions. If this value is set to true
, the system will try to execute transactions on the target chain, so sufficient balances are required. This value must be set to true
if it is the Bifrost Network.
true
/ false
-
evm_providers.eip1559
The flag which represents whether the system will execute EIP-1559 transactions. If set to false
, transactions will be executed by legacy types.
true
/ false
false
evm_providers.min_gas_price
The minimum gas price (in WEI) that the system will setup when executing legacy transactions. If the value is null, it will be dynamically set. This field only has effect when the eip1559
parameter is disabled.
30000000000
0
evm_providers.min_priority_fee
The minimum priority fee (in WEI) that the system will setup when executing EIP-1559 transactions. If the value is null, it will be dynamically set. This field only has effect when the eip1559
parameter is enabled.
30000000000
0
evm_providers.escalate_percentage
The percentage that will be used on gas price escalation to replace a transaction that is stuck in the mempool. This option will only have effect for legacy transactions.
15.0
15.0
evm_providers.is_initially_escalated
The flag whether if the gas price will be initially escalated. The escalate_percentage
will be used on escalation. This option will only have effect for legacy transactions.
true
/ false
false
evm_providers.get_logs_batch_size
The batch size (=block range) used when requesting eth_getLogs()
. If increased the RPC request ration will be reduced, however event processing will be delayed regarded to the configured value. Default size is set to 1, which means it will be requested on every new block.
5
1
sentry_config
Sentry related parameters. If this section does not exist in your configuration file, Sentry will be disabled.
-
None
sentry_config.is_enabled
The flag which represents whether Sentry is enabled.
-
-
sentry_config.environment
The identifier for the Sentry client. This value will be used to distinguish triggered alarms.
"mainnet"
""
sentry_config.dsn
The Sentry DSN. If the value has been set, error and warning alerts will be notified. If the value is empty, Sentry will be disabled.
-
-
prometheus_config
Prometheus related parameters. It this section does not exist in your configuration file, Prometheus will be disabled.
-
None
prometheus_config.is_enabled
The flag which represents whether Prometheus metric collection is enabled.
true
/ false
-
prometheus_config.is_external
The flag which represents whether the Prometheus server is exposed on all interfaces.
true
/ false
false
prometheus_config.port
The Prometheus exporter TCP port.
8000
8000
bootstrap_config
Bootstrap related parameters. Bootstrap is a process that will be executed whenever the relayer (re-)starts. It will collect historical CCCP events and let the relayer re-handle the event to prevent missed actions.
-
None
bootstrap_config.is_enabled
The flag which represents whether bootstrap is enabled
true
/ false
-
bootstrap_config.round_offset
The amount of rounds to search for missed events.
3
3
Last updated