Block.one, a Cayman Islands-registered open-source software publisher which helped develop EOS, one of the largest platforms for building decentralized applications (dApps), has launched “a release candidate” for EOSIO, the suite of software products powering the zero-fee smart contract platform.

As noted in an official blog post, published on April 30th, 2019 by Block.one, this latest “release candidate marks a major update for the EOSIO software platform.” As described by the blockchain-based software developer, the new candidate release for EOSIO is “a consensus protocol upgrade, which implements a change to the protocol rules and requires alignment.”

Current Version Is Only “A Release Candidate,” Seeking Feedback From Community

Block.one’s blog further noted that “block producing” or transaction validating nodes must install the release so that the upgrade can be “successfully deployed.” The software publisher clarified that “this is a Release Candidate for feedback, [and that] the official release will be marked stable in the coming weeks once we have finished vetting and testing the update with the community.”

After successfully completing the various phases of testing, the current release may be “promoted to stable,” Block.one’s management explained. Moreover, the stable release will introduce “foundational mechanisms [in order] to facilitate the activation of the consensus protocol upgrade.”

“Two-Thirds Of Active Majority BPs” Must Agree On “Activating Features”

According to Block.one, these particular mechanisms will “allow a two-thirds majority of active block producers (BP) of EOSIO blockchains to activate individual features of the consensus protocol upgrade to modify the protocol rules.”

Configuration of the new consensus protocol will require that “all [EOS network] nodes be locally [updated] to accept these upgrades,” a process which involves “installing a new version of the nodeos software.”

New Release Features Can Be “Activated Independently Of One Another”

As explained by Block.one: 

Each feature is for the most part designed to be à la carte, i.e. each feature can be activated independently of one another, however, some features may have dependencies on other features as noted in each issue.

The open-source software publisher added that “this feature is actually part of the foundational mechanisms to facilitate activation of consensus protocol upgrades and will, therefore, need to be the first feature that is activated.” Block.one’s blog also mentioned that “some features will be configured to require pre-activation on the blockchain.”

According to the EOS platform developer, this “enables replacing the subjective block producer policy of when to activate a particular feature with an objective on-chain policy carried out via smart contracts.”

Implementing Features With “An Objective On-Chain Policy”

In most cases, Block.one noted that “this objective on-chain policy will be in the form of requiring more than two-thirds of active block producers to approve an on-chain multisig transaction proposal.”

Once approved, the multisig transaction will “execute a special system contract action to pre-activate the particular feature.” As detailed in Block.one’s blog, the “PREACTIVATE_FEATURE feature must be activated before the new version of the system contract with that special action can be deployed.” That’s because “the action implementation will require a privileged intrinsic function only made available after PREACTIVATE_FEATURE is activated.”

As mentioned in Block.one’s documentation, there are “detailed recommendations” available for EOS users that are running a full-node. These are intended to guide block producers by providing instructions (and suggestions) on how to “test and update their systems for each feature to be implemented.”

All Node Operators, Not Just BPs, Must Carefully “Review Suggested Instructions”

Furthermore, Block.one noted that “all [full-node] operators (including non block-producing nodes) should review the suggested instructions as soon as possible because updating to EOSIO v1.8.0 will require a replay from genesis which can take some time.”

Other notable technical upgrades to EOSIO are as follows:

  • “(#6105) Modify restrictions on RAM billing; Codename: RAM_RESTRICTIONS,”
  • “(#6103) Fix problems associated with replacing deferred transaction; Codename: REPLACE_DEFERRED,”
  • “(#6115) Avoid transaction ID collision of deferred transactions; Codename: NO_DUPLICATE_DEFERRED_ID,”
  • “(#6333) Disallow linking to non-existing permission; Codename: ONLY_LINK_TO_EXISTING_PERMISSION,”
  • “(#6458) Disallow proposing an empty producer schedule,”
  • “(#6672) Fix excessive restrictions of eosio::linkauth; Codename: FIX_LINKAUTH_RESTRICTION,”
  • “(#6705) Restrict authorization checking when sending actions to self; Codename: RESTRICT_ACTION_TO_SELF”