Telos™ Core Developers — RFC: Telos Networks Upgrade to Nodeos 1.8.x and New Features Activation
The various blockchains operating on EOSIO software, including Telos™, have an opportunity to perform an upgrade to the current version, 1.8, which has the potential to cause breaking changes for any node or application on these networks.
Upgrading in Phases
The upgrade to EOSIO version 1.8 comprises two parts. The first part is to upgrade the consensus mechanism. Any nodes not updated to nodeos 1.8 or above will not be able to interact with the rest of the network once the consensus mechanism is upgraded. Block producers running previous versions of the software will fork off the network. Operating nodeos at version 1.8 requires a full replay of the network to sync before the node can activate, which can take several days. For this reason, the TCD and block producers have been preparing for this for some time now. We have made efforts to contact developers of wallets, block explorers, and app developers to make them aware of the proposed time and date of this activation, and have made daily postings of the article describing this initial Telos Mainnet 1.8 Activation timeline.
Upgrading to nodeos v.1.8 also requires updating the EOSIO system contracts to version 1.7.4. This requires additional developer work to ensure that the changes unique to Telos do not provide any unexpected interactions with the new version of nodeos. The TCD are taking this opportunity to also integrate new voting changes to the Trail Voting System v2.0 into Telos governance voting for worker proposals and ratify/amend ballots to re-align the voting weight of various states of tokens (liquid, staked to NET or CPU, staked to REX) to better match their weight in voting for block producers. for these types of ballots to better match the as described in the TCD Update of Sept 5, 2019.
The second part of the EOSIO 1.8 upgrade involves activating any number of new features that are made possible by the new consensus protocol. Many would consider these new features the primary reason to undertake this protocol change, as they offer significant enhancements to the EOSIO software to users and applications.
To facilitate the full value of the EOSIO 1.8 upgrade, the TCD, in conjunction with the block producers has been preparing a migration plan that includes not only the consensus protocol upgrade, but activation of the additional features as well.
Telos operates three types of networks: the Telos mainnet where value is recorded, the Telos testnet, where developers may test their own apps to ensure proper function before deploying to the mainnet, and temporary stage-nets where the block producers test software prior to deploying it to the testnet. Typically, new code is tested in the following order: stage-nets, testnet, mainnet. The proposed migration plan includes actions on all three Telos networks.
Activating Features
The new features provide an array of new functions which can be read about in this article. These new features broadly fall into three categories: “Safe changes” that will cause no errors or breaks in existing apps, “Breaking changes” that will cause program errors only in apps that use the previous versions of these features.
This migration plan intends to lay out a schedule for deploying these changes across the various Telos networks so as to test and rehearse them for block producers (on stage-nets), provide them for developers for testing and modifying their own apps (on the Telos testnet), and finally to deploy them to the Telos mainnet for general usage. A period of time has been provided between each activation to allow observation before additional changes are made.
These features fall into the following categories:
Safe Features
· ONLY_LINK_TO_EXISTING_PERMISSION
· FIX_LINKAUTH_RESTRICTION
· DISALLOW_EMPTY_PRODUCER_SCHEDULE
· ONLY_BILL_FIRST_AUTHORIZER
· GET_SENDER
· RAM_RESTRICTIONS
· FORWARD_SETCODE
Breaking Features
· REPLACE_DEFERRED
· NO_DUPLICATE_DEFERRED_ID
· RESTRICT_ACTION_TO_SELF
RESTRICT_ACTION_TO_SELF
The proposed phases of this migration are:
1. Consensus protocol
2. Activation of safe features in one group
3. Activation of remaining safe features
4. Activation of breaking features
Proposed Rollout Schedule
The following chart details the proposed upgrade schedule for all elements discussed. Features activation on the Telos testnet will occur in a phased rollout, but all on the same day so as to provide app developers the maximum amount of time to modify and test their apps.
###
About the author: Telos architect and whitepaper author Douglas Horn leads the Telos Core Developers. He is the founder of GoodBlock.io.
