Ad
News
Ethereum Founder Vitalik Buterin Helps Daniel Larimer Code, Says EOS “Not Actually Safe” Ethereum Founder Vitalik Buterin Helps Daniel Larimer Code, Says EOS “Not Actually Safe”
🚨 This article is 7 years old...

Ethereum Founder Vitalik Buterin Helps Daniel Larimer Code, Says EOS “Not Actually Safe”

Ethereum Founder Vitalik Buterin Helps Daniel Larimer Code, Says EOS “Not Actually Safe”

Photo by Cindy Tang on Unsplash

The EOS development team is currently working at high speed ahead of the scheduled mainnet launch on the 2nd of June when EOS will migrate from the Ethereum network onto its own blockchain over the course of 40 days. The dev team has had unexpected assistance, however, from Ethereum co-founder Vitalik Buterin, who has taken to the EOS GitHub to critique the project.

In a series of comments on a loss of consensus issue posted by EOS CTO Dan Larimer, Buterin expressed concerns regarding the safety of a solution presented by Larimer, critiquing Larimer’s now-closed resolution that is intended to ensure that EOS’s Delegated Proof of Stake 3.0 protocol will not fall out of consensus.

Buterin Weighs in on EOS: Just Use Casper

Related Story: Ethereum Founder Vitalik Buterin: Sharding is Coming

Buterin’s concerns with the development of the EOS project appear to stem from the similarities between Larimer’s solution to the consensus issue presented and Ethereum’s Casper FFG algorithm — the conditions described are functionally equivalent to the “no double vote” and “no surround vote” slashing conditions present in Casper FFG.

On May 15, Buterin commented on the solution, stating that the solution presented “does not seem to actually be safe,” advising Larimer:

“In general, it’s not possible to achieve BFT safety on a block without at least two messages from most nodes that directly or indirectly reference that block; this algo tries to do it in one round and it’s likely impossible to actually do that safely. If you want an intuitive and good way of doing this, I recommend just using the algorithm in our Casper FFG paper”

Buterin’s underhanded recommendation that EOS “just use Casper FFG” is relatively valid given the solution presented by Larimer — in Buterin’s own words:

“If so, then as long as you add source checkpoint references (see the Casper FFG paper) and add certain slashing conditions around those, then you’ve basically got Casper FFG.”

The “assistance” provided by Buterin regarding the consensus issue isn’t the first time Buterin has expressed concerns regarding the EOS project — the Ethereum co-founder took a question at the Ethereum Shenzhen Meetup Launch Event in 2017 regarding EOS. The Delegated Proof of Stake consensus method via which EOS achieves consensus, according to Buterin, is dangerously centralized:

“Larimer has this concept called DPOS where he says that in DPOS you only need about 100 nodes in the network … The problem is that if you have 100 nodes the system is much more centralized. You can denial of service them. Because you have to vote for them, the nodes that win are going to be the nodes that everyone knows. So it is much easier to attack the people running the nodes. ISPs can shut them down, companies can shut them down, governments can shut it down fairly easily.”

The benefits offered by the EOS DPOS protocol, however, are obvious. As EOS “supernodes” are voted in by the EOS community, EOS architecture is arguably resistant to corruption. Ethereum hashing power is, in fact, more centralized than the proposed EOS distribution. Data available from EtherChain shows that just three pools control 51% of the hash power, making it possible for them to trivially ignore blocks produced by all other pools.

EOS Development Powers Ahead

Regardless of Buterin’s position on the EOS development process EOS appears to be moving ahead smoothly, with Block.One — the organization behind the EOS project — recently capturing the Chief Financial Officer of the largest bank in Australia as the COO of the organization.

Mentioned in this article
Posted In: , , Technology