.svg)
.svg)
.svg){kind=icon}
.svg){kind=icon}
.svg){kind=icon}
%201.svg){kind=icon}
.svg){kind=icon}
%201.svg){kind=icon}
%20(1)%201.svg){kind=icon}
.svg){kind=icon}
.svg){kind=icon}
%201.svg){kind=icon}
A hard fork is planned at Fuse Network block 13,800,000, estimated to be published on November, 7th. It will introduce into blockchain’s node software a series of ten Ethereum upgrades. Fuse network nodes will thus migrate to the OpenEthereum client.
Information for validators and nodes wishing to upgrade can be found here.
Since its launch in 2019, the Fuse Network blockchain has processed over 18 million transactions, generated over 500,000 wallet addresses, and is supported by 45 active validators.
Fuse Network Mechanics
Fuse’s blockchain utilizes a version of delegated proof of stake (dPoS) mechanism for Sybil protection and the Authority Round (AuRa) algorithm for achieving consensus among validators.
When approved by the quorum of validators, each transaction on Fuse Network is executed by each of the network’s full nodes. In practice, this means that certain operations need to be done within each node’s virtual machine (VM). The elementary computing operations that constitute a transaction are called “opcodes”. Each opcode has a predefined “gas” price.
Gas is a value that reflects the computational difficulty of a VM operation. Each block on Fuse Network is allocated the same amount of gas: 10 million (expected to be raised to 15 million soon). This means that it can only contain transactions whose total difficulty does not exceed 10 million gas. Network validators set the minimum fee in FUSE per unit of gas with the actual fee determined by demand.
The software run by Fuse Networks nodes is called a “network client.” When we talk about Fuse Network upgrades, we are referencing coordinated changes made to the network client. It has already undergone several upgrades through the adoption by validators of Fuse Improvement Proposals (FIPs). So far, FIPs 2, 3, 4, 8, and 9 have been passed, and FIP 11 is about to be adopted in order to punish validators that do not meet uptime requirements.
The Block 13, 800, 000 Hard Fork
In order to remain compatible with current network node softwares that function within the Ethereum ecosystem, a range of network upgrades will be implemented. They will constitute a hard fork that will become live at Fuse Network block no. 13, 800, 000. The estimated date of this block is November 7th.
The term “hard fork” here does not imply that the change is contentious. It simply means that the network nodes will need to install the new node software to continue running on the upgraded version of Fuse Network.
All upgrades included into the fork involve optimizations of how Fuse Network’s virtual machine executes transactions and stores data.
We refer below to EIPs and not FIPs because they are Ethereum Improvement Proposals adopted directly.
A brief description of each EIP can be found below:
EIP 152. enables the BLAKE2b hash function and other higher-round 64-bit BLAKE2 variants to run cheaply on the Fuse Network VM.
EIP 1108. Changes the gas price for arithmetic precompiles for elliptic curves which can be used, among other things, to improve scaling, construct confidential transactions.
EIP 1283. Introduces a scheme for reducing gas cost for smart contract storage.
EIP 1344. Adds an opcode that returns the current chain’s EIP-155 unique identifier to prevent replay attacks between chains.
EIP 1706. Adds a condition for executing the SSTORE opcode according to which the smart contract should have a minimum amount of gas left.
EIP 1884. Raises the gas price of three VM opcodes and introduces a new opcode. The goal is to prevent overloading the VM with certain transactions.
EIP 2028. Reduces the gas cost of Calldata operations.
EIP 2565. Introduces a scheme for calculating the gas cost of the important ModExp (modular exponentiation) precompile.
EIP 2929. Increases the gas cost of certain storage-addressing opcodes when they are used for the first time in a transaction.
EIP 2930. Introduces a new transaction type with the list of accessed addresses and storage keys.
In order to implement the hard fork, network node operators will need to upgrade to the latest Fusenet docker image 2.0.1 which is built on the OpenEthereum network client software. The guide on how to implement the upgrade is available here.
Migration to Nethermind
Following the implementation of this hard fork at block 13,800,000, we are planning to continue upgrading the network software to the latest Ethereum standard. Implementing the EIPs required will allow Fuse nodes to switch to the Nethermind client that is being actively maintained in parrelel to Open Ethereum. This is expected to happen at the end of Q4 2021 — early Q1 2022.
Follow our social media channels to stay updated on recent news and developments at
