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.
Summary
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.
Client Upgrade
- 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.
Medium Impact
Balance check before transaction executions
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.
Provide customizable eth_getLogs batch size
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.
Support compatibility between EIP-1559 and Legacy typed transactions
The 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.
Low Impact
Improve on-start verifications
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
eth_chainId. - 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 secondsevm_providers.block_confirmations: [0, 100] → max 100 blocksevm_providers.escalate_percentage: [0.0, 100.0] → max 100%evm_providers.escalate_interval: [0, 60] → max 60 secondsevm_providers.duplicate_confirm_delay: [0, 60000] → max 60 secondsevm_providers.get_logs_batch_size: [1, 60 seconds / call_interval] → max to the number of blocks the target chain averagely mines per minutebootstrap_config.round_offset: [0, 64] → max 64 rounds
Process to update bifrost-relayer.rs client
Please follow the steps below to update your relayer client.
Step 1.
First, remove or backup the previous bifrost-relayer binary file.
rm <PATH_TO_BIFROST_RELAYER_BINARY>
Step 3.
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
Step 4.
At last, restart the Systemd service.
sudo systemctl restart bifrost-relayer