There is no problem putting a code of a protocol upgrade to the network and announcing the availability of it within some block. The problem starts when such a code is not backward compatible. The network partitioning will evidently happen as a result of such code spontaneous upgrade of network nodes.

To tackle that, the Ever OS upgrade procedure should be as follows. The code should be pushed into the production branch in the DeGit repository which will upload it to the DriveChain and upgrade a smart contract responsible for network code upgrade. Once validators detect such an upgrade is available, they should start a fresh node with such an upgrade, sync with the necessary WorkChain and a MasterChain and signal their availability for validation to the D’Elector contract of choice. The D’Elector will launch a pre-validation procedure that will verify fake blocks with new versions until the necessary number of such nodes are available on the network. Whenever that happens, the D’Elector will issue a key block in which the new validator set becomes the active one. The next block after the keyblock will have a new format, a new version and no blocks produced by the old software will be accepted.

Last updated