The following report is a set of changes that deserves to be highlighted due to their impact on the Bifrost Network. Highlights are categorized into High Impact, Medium Impact, and Low Impact for ease of navigation.
For more information on setting up your relayer please follow our official documentations.
This report analyzes the recent updates to the Bifrost Network’s (CCCP) Relayer. The primary feature of this release is its improvements on state verifications, as well as resource optimization. The target client is bifrost-relayer.rs (Rust) that has been updated to accommodate these changes.
- V1.0.3 → V1.0.4
Please note that it is recommended to upgrade your Relayer client and configurations if you’re operating a Relayer on our Mainnet or Testnet.
Previously, the built-in
TransactionManager didn’t have any existing business logic of remaining balance checks. Due to this issue, transactions has been executed even though the relayer’s account had insufficient funds to pay transaction fees, that occurred to unexpected system failures and wasting funds. To prevent the issue, the
TransactionManager now verifies whether the relayer’s account has sufficient funds or not, before executing every single transaction. If it ends up into insufficient funds, the system will be gracefully shutdown to restrain further failures. In order to track system failures, we highly recommend to attach Sentry or any other alerting tools to your relayer system to properly respond to a matter or situation.
In default, the built-in
BlockManager will periodically read every blocks whether it contains CCCP events. This process is worked through by utilizing the JSON RPC method,
eth_getLogs. This method has the feature to search certain contract event logs that had been emitted among the given block range. In most cases,
eth_getLogs will consume high resources of your running node, and this is not exceptional for node provider services. We now provide customizable
eth_getLogs batch size to optimize and reduce your resource usages, instead of using a constant single block batch per request.
In order to setup your batch size, it’s required to update your configuration YAML file. First, add the
get_logs_batch_size parameter with the batch size (in blocks) into the EVM provider that requires higher batch sizes as below (A system restart is required). The default batch size is 1.
- name: "base" id: 84531 provider: "<YOUR_BASE_GOERLI_RPC_ENDPOINT>" call_interval: 2000 block_confirmations: 7 is_relay_target: false eip1559: true get_logs_batch_size: 3 socket_address: "0x9c8B701961C20d006cb7c4B5B91c6cb93EdB44Ac" vault_address: "0x6EeE91b7c69e3576C13cE7a9C7C0E305dF6996F9" authority_address: "0xb3f5C3a2237Df09F94dDAC32F63E5D962Ae66a42"
Please note that custom setups will lead to certain tradeoffs as below.
- Higher batch size → Lower resource usage. However, longer delays required to process a single CCCP event.
TransactionManager is customizable whether transactions will be executed in an EIP-1559 or a legacy format. This option can be configured by providing the
eip1559 parameter into your configuration YAML file. However, in a very low probability, we have reached to an unexpected issue when the executed transaction has been stuck to the memory pool. While the transaction stays in the memory pool and when the system has been restarted with a switched
TransactionManager type (either from EIP-1559 to Legacy, or vice versa), the transaction replacement process will not work properly due to the type incompatibility (The
TransactionManager tries to replace the stuck transaction on-start). The
TransactionManager will now handle the incompatibility issue by converting the transaction to the correct format before the replacement.
The on-start process has been improved by adding some verification logics. The following verifications are to prevent unexpected system behaviors. If any verification is unsuccessful, the system won’t start.
- Compare the configured chain ID specified in your configuration YAML file with the actual response from your connected node by
- Check if the configured account has at least the specified minimum amount (=1 BFC).
- Verifies whether the following numeric parameters exceeds the maximum limit.
evm_providers.call_interval: [0, 60000] → max 60 seconds
evm_providers.block_confirmations: [0, 100] → max 100 blocks
evm_providers.escalate_percentage: [0.0, 100.0] → max 100%
evm_providers.escalate_interval: [0, 60] → max 60 seconds
evm_providers.duplicate_confirm_delay: [0, 60000] → max 60 seconds
evm_providers.get_logs_batch_size: [1, 60 seconds / call_interval] → max to the number of blocks the target chain averagely mines per minute
bootstrap_config.round_offset: [0, 64] → max 64 rounds
Please follow the steps below to update your relayer client.
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)
wget "https://github.com/bifrost-platform/bifrost-relayer.rs/releases/latest/download/bifrost-relayer" chmod +x bifrost-relayer
At last, restart the Systemd service.
sudo systemctl restart bifrost-relayer