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.
Summary
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 polkadot-sdk@v1.3.0 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.
Client Upgrade
- V1.2.5 → V1.3.0
Client Upgrade Recommendation Levels
- Full Nodes, RPC Nodes:
MEDIUM - Basic Nodes, Others:
LOW
Substrate and Frontier Upgrade
- V0.9.43 → V1.3.0
Runtime Upgrades
- TESTNET : V463 (upgraded at
#13848812) - MAINNET : V2020 (scheduled at
#11450760)
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.
Bifrost pallet improvements
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
- Replace
OrderedSetwithBTreeMap&BTreeSet - 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
Polkadot SDK migration: v1.3.0
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.
Please note that the previous forked repository, bifrost-substrate, is now deprecated. Further development will be made on the new forked repository, polkadot-sdk.
Notable Updates
- [Frontier] Support
eth_getBlockReceiptsJSON RPC (ref.) - [Substrate] Remove execution strategies (ref.)
- [Substrate] Revamp pallet preimage (ref.)
Patch Rust EVM
PR: NODE-86, deps: patch rust-evm by dnjscksdn98 · Pull Request #35 · bifrost-platform/bifrost-node
Recently, there was a CVE report that affected Rust EVM.
Rust EVM is an Ethereum Virtual Machine interpreter. In
rust-evm, a feature calledrecord_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 aCREATEorCREATE2, in the case that the substack execution happens successfully,rust-evmwill first commit the substate, and then callrecord_external_operation(Write(out_code.len())). Ifrecord_external_operationlater fails, this error is returned to the parent call stack, instead ofSucceeded. 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 customrecord_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.
JSON RPC response format update: web3_clientVersion
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.
"thebifrost-dev/v305.1/fc-rpc-2.0.0-dev"
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.
"bifrost-node/v1.3.0-246a9815fbf/macos-aarch64/rustc1.75.0"
Add a delay on relayer address update
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.
Process to update node client
Please follow the steps below to update your node client.
Step 1.
First, stop your bifrost-node service and remove the installed executable binary file.
systemctl stop bifrost-node.service
rm /var/lib/bifrost-data/bifrost-node
Step 2.
Then, re-download the latest bifrost-node binary.
wget "https://github.com/bifrost-platform/bifrost-node/releases/latest/download/bifrost-node"
Step 3.
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
Step 4.
At last, restart your bifrost-node service.
systemctl restart bifrost-node.service