EOS Drama Continues As Heated Exchange With Block Producer Emerges

Avi Rosten

The ongoing drama surrounding the EOS platform’s controversial consensus mechanism took another interesting turn today - as a screenshot apparently showing a conversation with an EOS block producer (BP) has emerged.

Posted as an image on popular subreddit r/cryptocurrency, the screenshot shows a heated Telegram exchange between an EOS block producer, and another unidentified EOS participant - who chastises the BP for failing to freeze some accounts as directed by the EOS Core Arbitration Forum (ECAF):

eos chat.jpg

While the authenticity of the conversation has yet to be confirmed, the post has generated a stir on social media, with popular cypto figure Whalepanda chiming in on Twitter:

As recently covered on CryptoGlobe, this aspect of the EOS governance model has been highly controversial within the crypto community - as many critics have pointed out that the 21 block producers act in principle as a highly centralised concentration of power.

Despite the fact that EOS allows for BPs to be continuously elected, because of the enormous centralisation of the token’s holdings - the system effectively ensures that EOS whales exert a massively disproportionate influence over who is elected (as argued yesterday).

This latest revelation - if legitimate - again seems to underscore the problems associated with a system that places too much power in the hands of individuals.

Not only does it illustrate the problems of a protocol which might fail to punish bad actors, but it also points to a worryingly dystopian form of governance - where a kind of central committee issues diktats, backed up with threats of legal action.

While the future of one of the world’s largest cryptoassets remains unclear for now, it seems reasonable that token holders might start to question the platform’s organisation if instances such as this one continue to emerge.

Block.one Publishes 'Release Candidate' for EOS, Includes Enhanced 'Security Features'

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”