Once a new node's binary is ready to be deployed on one of the networks (mainnet, testnet or devnet), nodes operators must perform the upgrade to the newest version. These releases are always announced on Elrond Validators chat plus via other communication channels, depending on the case.
Types of upgrades
Currently, we have the following types of upgrades:
A. - all nodes need to upgrade: upgrades that involve processing changes with an activation epoch (as explained below) and have to be performed by all nodes operators in order to keep the same view over the network and not cause service disruptions.
B. - optional upgrades: upgrades that, for example, simply add a new Rest API endpoint or improve the trie syncing timing are not critical from a processing point of view, and they are optional. If the nodes operators think the new feature will help them, they can proceed with the upgrade without losing the compatibility with the network.
C. - only validators need to upgrade: upgrades that, for example, include new features that only trigger validators (ratings changes, transactions selection improvements and so on). Observers (nodes that don't have a stake attached) don't need to perform the upgrade (but can upgrade nonetheless if desired).
In order to make the upgrades as smooth as possible and to ensure that each node has the same view over the network at a given moment, Elrond has a so called activation epoch mechanism that allows the node to implement both behaviors of the protocol - the old (current) one, and the new one, planned for activation at a specific epoch. This mechanisms ensures that, until the protocol change becomes active, nodes with an upgraded codebase / binary remain compatible with nodes that did not perform the upgrade, and consensus is held. Although this happens in 99.9% cases, this is not 100% guaranteed due to the unforeseen consequences when upgrading the code base in parallel with executing transactions generated by 3rd parties (Elrond blockchain users)
Deterministic time / height for upgrades
As compared to other protocols that perform upgrades that start at a specific block height, releases for Elrond nodes don't have a specific block height where the new updates become effective, but rather the first block in the activation epoch will make the nodes proceed with the updated versions of the components.
Since the height of the first block in an epoch cannot be known in advance (due to possible roll-backs), the network height where a feature becomes effective cannot be calculated.
However, the time when a new feature of a bugfix becomes effective can be calculated, as epochs have fixed lengths in rounds.
Currently, Elrond Mainnet has epochs of
14,400 rounds and a round is
6 sec. This results in a
24h epoch. However,
there can be delays of a few rounds, due to rollbacks of the start of epoch metablocks.
Activation epoch example
For example, let's say that we want to introduce a feature so that smart contracts can receive a
PayableBySC metadata that
will allow them to receive EGLD or other tokens from other smart contracts.
the Elrond Mainnet is at epoch
currently, the node binary doesn't know about the
PayableBySCmetadata so if one wants to try it, an error like
invalid metadatawill be returned.
600, we release a new node binary that contains the
PayableBySCmetadata that will become active starting with epoch
all nodes operators perform the upgrade.
613begins, the new feature activates and the new metadata is recognized and accepted.
if one wants to issue a smart contract that is
PayableBySC, it will work.
nodes that didn't perform the upgrade will produce a different output of the transaction (as compared to the majority) and won't be able to keep up with the rest of the chain.
Backwards compatibility explained:
If one wants to process all the blocks since genesis (via
full archive or via
import-db) with the released binary
it will behave this way:
- if for example, in epoch
455there was a transaction that tried to set the
PayableBySCmetadata, it will process it as
- for transactions in epochs newer than
613it will process the new metadata.
|Epoch < 613||Epoch >= 613|