Who Could Have Predicted Blockchains Would Melt Down Based on Operational Issues?

by Tim Sloane 0

The article “The EOS Arbitrator Problem: A Crypto Governance Breakdown Explained” in Coindesk highlights the importance of having a well-managed and organized governing body in charge of development and operations of any blockchain that will be used by businesses. The Blockchains that Mercator expects have the highest chance of success all have their operational aspects locked down, including Ripple and Sovrin as we described years ago here.

The management team which establishes rules and software deployment priorities must all be participants in the network and must all share common goals. Blockchains deployed without such an organizational structure or that fail to tie the software implementation to a specific use case will find it extremely difficult to address those issues that are unique to a specific use case.

In the case of EOS the decision making process associated with vetting who can operate network nodes fell apart:

“”They have to figure their own shit out.”

Those were the harsh words of one of EOS’ top “block producers” – the network participants in charge of maintaining the blockchain – on Monday as the world’s fifth largest cryptocurrency attracted public ridicule for its current state of confusion.

As told to CoinDesk by Kevin Rose, co-founder and head of strategy at EOS New York, the statement could reflect the broader snags the software has faced since release, but this comment was focused specifically on the EOS Core Arbitration Forum (ECAF).

So far, it seems many both inside and outside the EOS community aren’t clear what ECAF, the main body tasked with resolving disputes between token holders on the network, is and what control it has over transactions.

That’s largely because ECAF’s role and duties were discussed back and forth over months of forum discussions, but clear methods and processes don’t seem to have been decided on. It’s become apparent over the past few days that this mess of information now needs to be organized and clearly communicated to the community.

Stepping back, all this turbulence began on June 17, just three days after the network’s launch, when the network’s top block producers unanimously intervened to stop seven addresses from making transactions. That decision was retroactively endorsed by an ECAF order (the arbitrator had initially refused to rule on the issue).

Then on June 22, an order made the rounds that ECAF wanted to freeze 27 more accounts, to which “the logic and reasoning … will be posted at a later date.” On June 24, another order was seemingly issued, demanding that tokens be revoked from some addresses.

That order, however, turned out to be a fake.

With all the mayhem, EOS New York made a big decision. Until it can be reasonably certain about their authenticity, the block producer wrote on Sunday, it will ignore ECAF decisions – or decisions that appear to be ECAF decisions.

“We cannot with confidence execute any statement claiming to be an ECAF opinion,” the organization said, adding:

“We will resume normal processing once communications can be established on-chain such that they can be audited by both EOS New York and the community.”

Adding to that, Rose pointed to what he called a “rampant misunderstanding about what arbitration is” on the EOS network. According to him, ECAF needs improved processes, more transparency and ultimately, competition.

Roshan Abraham of EOS Authority, another top block producer, agreed that ECAF’s processes are flawed. Meanwhile, EOS Telegram chats are abuzz with complaints, speculation and unanswered questions about the arbitrator.”

The issues of this EOS case also raise awareness regarding the challenges associated with matching an appropriate consensus algorithm (that vets blocks and maintains trust) with the administrational decision of which entities are allowed to operate nodes in a Permissioned Public or Permissioned Private blockchain. The less trust there is in a block producer (trust is a bedeviling attribute to gauge) the more stringent the consensus algorithm must be. The more stringent the consensus protocol, generally the slower the network operates. This challenge of selecting an appropriate consensus protocol is made more difficult because there are a slew of consensus protocols available but no validation methodology to determine how well any of these work based on varying configurations and trust requirements.

Overview by Tim Sloane, VP, Payments Innovation at Mercator Advisory Group

Featured Content