# Bifrost Node Release Analysis v1.3.0 **URL:** \ **Category:** Ecosystem\ **Created:** [February 6, 2024, 4:54am UTC](https://forum.bifrostnetwork.com/t/bifrost-node-release-analysis-v1-3-0/345 "2024-02-06T04:54:12Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![BIFROST-Team](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.bifrostnetwork.com/bifrost-team/32/164_2.png) [@BIFROST-Team](https://forum.bifrostnetwork.com/u/BIFROST-Team)\ **Post date:** [February 6, 2024, 4:54am UTC](https://forum.bifrostnetwork.com/t/bifrost-node-release-analysis-v1-3-0/345/1 "2024-02-06T04:54:12Z")
⚠ 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](https://docs.bifrostnetwork.com/bifrost-network). # **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** PR: [NODE-79, bifrost pallets improvements by alstjd0921 · Pull Request #34 · bifrost-platform/bifrost-node](https://github.com/bifrost-platform/bifrost-node/pull/34) 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 `OrderedSet` with `BTreeMap` & `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** PR: [NODE-65, deps: polkadot sdk migration by dnjscksdn98 · Pull Request #36 · bifrost-platform/bifrost-node](https://github.com/bifrost-platform/bifrost-node/pull/36) 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](https://github.com/bifrost-platform/bifrost-substrate), is now deprecated. Further development will be made on the new forked repository, [polkadot-sdk](https://github.com/bifrost-platform/polkadot-sdk). **Notable Updates** - [**Frontier**] Support `eth_getBlockReceipts` JSON RPC ([ref.](https://github.com/polkadot-evm/frontier/pull/1156)) - [**Substrate**] Remove execution strategies ([ref.](https://github.com/paritytech/substrate/pull/14387)) - [**Substrate**] Revamp pallet preimage ([ref.](https://github.com/paritytech/polkadot-sdk/pull/1363)) # **Patch Rust EVM** PR: [NODE-86, deps: patch rust-evm by dnjscksdn98 · Pull Request #35 · bifrost-platform/bifrost-node](https://github.com/bifrost-platform/bifrost-node/pull/35) Recently, there was a [CVE report](https://www.opencve.io/cve/CVE-2024-21629) that affected Rust EVM. > Rust EVM is an Ethereum Virtual Machine interpreter. In `rust-evm`, a feature called `record_external_operation` was 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 `CREATE` or `CREATE2`, in the case that the substack execution happens successfully, `rust-evm` will first commit the substate, and then call `record_external_operation(Write(out_code.len()))`. If `record_external_operation` later 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_operation` that 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`** PR: [NODE-84, chore: web3\_clientVersion response format by alstjd0921 · Pull Request #37 · bifrost-platform/bifrost-node](https://github.com/bifrost-platform/bifrost-node/pull/37) 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. ```auto "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. ```auto "bifrost-node/v1.3.0-246a9815fbf/macos-aarch64/rustc1.75.0" ``` # **Add a delay on relayer address update** PR: [NODE-78, fix: delayed relayer address update by dnjscksdn98 · Pull Request #38 · bifrost-platform/bifrost-node](https://github.com/bifrost-platform/bifrost-node/pull/38) 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. ```auto systemctl stop bifrost-node.service rm /var/lib/bifrost-data/bifrost-node ``` **Step 2.** Then, re-download the latest bifrost-node binary. ```auto 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. ```auto 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. ```auto systemctl restart bifrost-node.service ```