The following report is a set of changes that deserves to be highlighted due to their impact on the Bifrost Network. For more information on setting up your node please follow our official documentations.
This report outlines the recent updates to the Bifrost Network’s Node client and runtime. The main feature of the new release is the upgrade to
email@example.com within Substrate and Frontier frameworks. Furthermore, this version introduces notable improvements in performance and efficiency across native runtime pallets, including our staking pallet. For further details, please see the comprehensive descriptions that follow.
- V1.2.5 → V1.3.0
Client Upgrade Recommendation Levels
- Full Nodes, RPC Nodes:
- Basic Nodes, Others:
Substrate and Frontier Upgrade
- V0.9.43 → V1.3.0
- TESTNET : V463 (upgraded at
- MAINNET : V2020 (scheduled at
Please note that upgrading your Bifrost Node client is recommended after the runtime upgrade occurs. If you’re operating a node or a relayer on our Mainnet or Testnet, please check the runtime upgrade schedule.
The Bifrost Node, which includes native runtime modules like a staking pallet, had areas identified for enhancement to boost runtime performance and efficiency. These improvements have now been applied across all our native runtime components.
- Refactoring to improve code readability and performance
- Remove unnecessary
clone()s. or partially clone.
- Remove redundant codes
- Remove dead code
- Migrate to new standard storage version
- Remove possibly panic points as much as possible
- Remove unnecessary path prefixes
- Fix wrong revert message in precompiles
The Bifrost Node’s runtime and client, initially built with archived Substrate libraries targeting branch
v0.9.43, have now been fully migrated to the official Polkadot SDK. This move aligns our development practices with the industry standard for Substrate-based chains. Moreover, we’ve updated the target branch to
v1.3.0, leading to significant enhancements in both the native runtime and client. For more specifics, please see the linked PR.
- [Frontier] Support
eth_getBlockReceiptsJSON RPC (ref.)
- [Substrate] Remove execution strategies (ref.)
- [Substrate] Revamp pallet preimage (ref.)
Recently, there was a CVE report that affected Rust EVM.
Rust EVM is an Ethereum Virtual Machine interpreter. In
rust-evm, a feature called
record_external_operationwas introduced, allowing library users to record custom gas changes. This feature can have some bogus interactions with the call stack. In particular, during finalization of a
CREATE2, in the case that the substack execution happens successfully,
rust-evmwill first commit the substate, and then call
record_external_operationlater fails, this error is returned to the parent call stack, instead of
Succeeded. Yet, the substate commitment already happened. This causes smart contracts able to commit state changes, when the parent caller contract receives zero address (which usually indicates that the execution has failed). This issue only impacts library users with custom
record_external_operationthat returns errors. The issue is patched in release 0.41.1. No known workarounds are available.
By evaluating the concern, we determined it posed minimal risk to the Bifrost Network. Nonetheless, to eliminate the possibility of any future issues, we swiftly applied a patch to Rust EVM and successfully updated both the Mainnet and Testnet.
Minor updates have been applied to one of our JSON RPC methods,
web3_clientVersion. Previously, the RPC response returned the runtime version followed by its related crate version as below.
This response format had some differences between the standard Geth node client and seems to be useless in most of the cases. We have customized the response format to follow Geth’s style to bring us meaningful data as below. The response now contains the target node client’s version, OS system information, and also the Rust version.
Previously, updating a registered relayer address using the
set_relayer extrinsic had zero delays. So the new address instantly applied to the network. However, the instant update seems to be error prone in some cases. To prevent any further issues, relayer address updates will now hold a one round delay in order to be applied to the network. So, when the
set_relayer extrinsic is requested, the previous address will be replaced at the beginning of the next round.
Please follow the steps below to update your node client.
First, stop your bifrost-node service and remove the installed executable binary file.
systemctl stop bifrost-node.service
Then, re-download the latest bifrost-node binary.
Now, the installed binary must be granted execution permission and moved to your chain data directory.
chmod +x bifrost-node
chown BIFROST_SERVICE bifrost-node
mv bifrost-node /var/lib/bifrost-data
At last, restart your bifrost-node service.
systemctl restart bifrost-node.service