Vitalik Buterin recently [took a question about EOS at the Ethereum Shenzhen Keynote](https://youtu.be/SuY6L1nhWxM?t=495). Today I would like to provide some factual corrections to his claims about EOS. I will do this by addressing each of his points one at a time. 

https://youtu.be/SuY6L1nhWxM?t=495

At 8:20 minutes into the above video Vitalik Buteran says:

> The reason why EOS says that they can process more transactions comes from two sources. One of them is there are a lot of protocol features that Ethereum has EOS doesn’t have. One of them, for example, was merkle trees. So this if you want to prove anything about a transaction then anyone in the network can prove it. And you actually don’t need that much computing power to prove that the state of that account is some number and that the transaction was included. EOS does not have this.

[EOS does have a merkle tree over all the transactions within a block](https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md#merkle-proofs-for-light-client-validation--lcv-). This means it is possible to prove you have been paid without having to process all blocks nor trust the full nodes. In fact, these proofs are smaller than ETH because light nodes don’t even require the full history of block headers.

I have previously addressed the issue of generating Merkle Tree’s over state in my blog post titled [Blockchain State Representation should be Abstract and not part of Consensus](https://steemit.com/etheruem/@dantheman/blockchain-state-representation-should-be-abstract-and-not-part-of-consensus).  I have also made the analogy that Blockchain state is like [Schrödiger’s cat](https://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat), you can never actually observe it or prove anything about it except by opening the box to find out if the cat is dead or alive.  More specifically, while you can prove what the state was 1 minute ago (when you last opened the box), you cannot prove what the state is right now.  At any time a transaction could mutate that state and it will no longer be the same as when you read it.  The only exception is the use of “time locks” that assert the state cannot be modified for some time. Heavy use of time locks will crush performance and is of limited application.

> What this means is that if you are participating in the EOS network and you do not have a full node, that means a node that is processing all of the transactions. Then that means you have to trust the full nodes. That there is no way to verify for yourself that everything is happening correctly.

EOS is designed to allow nodes that validate partial state. This means that not all nodes need to run every contract. This in turn means it is possible to know the state of the applications and contracts you care about without having a highly resource demanding full node. Second, light clients can prove what actions users took (transactions), therefore, they can prove payment. Third, if a proof is really necessary they can broadcast a transaction that will assert the state they care about. If you cannot find multiple independent sources of blockchain truth that you can cross reference then you have bigger problems. Finally, everyone in the EOS ecosystem is contractually bound by a constitution and if the API nodes lie about blockchain state there will be cryptographic evidence of their lie and they can be held accountable for damages.

In Ethereum you have to trust the light clients are validating proofs and syncing from the proper blockchain. The merkle proofs you do generate about state are quickly dated and irrelevant. 

## Attacking DPOS

Next Vitalik goes on to attack Delegated Proof of Stake.

> The number of full nodes in EOS is going to be smaller.  So Dan Larimer has this concept called DPOS where he says that in DPOS you only need about 100 nodes in the network and consensus happens among these full nodes and everyone else is a thin client. The other reason it (EOS) claims it can process more transactions is because the requirements (bandwidth, computing) for each of these full nodes is much higher. This is one way to achieve scalability. 
> 
> 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. That particular path to scalability does come at a fairly high cost and that cost is that if you try to achieve scalability by having larger nodes then the number of nodes becomes much smaller is that that makes the system more centralized. 

His basic argument is that there are fewer full nodes and that they are easily identified and can be shut down by governments. He goes on to say that achieving scalability by having larger nodes makes the system more centralized. This of course demands a comparison, “more centralized than what”.

Here is the distribution of block producing nodes on Ethereum. As you can see two pools control 51% of the hash power and can trivially ignore blocks produced by all the other pools. 

<div class="pull-right">

![](https://steemitimages.com/DQmRmDVbfqF1aYtUkbXTWxYB1XQWgA9s2hwDFXChueh3tDE/image.png)

</div>

The next fact is that for all practical purposes ETH full nodes are already too resource intensive for the vast majority. On top of that almost all light clients don’t even bother with the merkle proofs that Vitalik claims are so valuable. 

The fact of the matter is that when it comes to block producers, Ethereum and every other protocol is far more centralized than the DPOS blockchains; especially when you use [meaningful definitions of centralization](http://bytemaster.github.io/article/2015/01/13/Decentralization-of-Nxt-vs-BitShares/) (such as number of unique producers per transaction confirmation window).

## The Black Market

Vitalik’s final point is that DPOS can be shut down far more easily by governments, ISPs, and corporations. This point is built on top a foundation of false assumptions regarding decentralization that I have already proven above.  The fact of the matter is that Ethereum and Bitcoin have already suffered denial of service attacks where as Steem and BitShares have not despite attempts to flood the network.  As the pie chart above demonstrates, it would be trivial to cripple Ethereum’s network by taking out 90% of the hash power with 7 nodes. 

The elephant in the room is that all of these public blockchains rely upon a peer-to-peer discovery process. Governments and ISPs around the world know exactly where every Ethereum node is and can trivially shutdown any and all public endpoints. 

We have already established that Etheruem full nodes are too impractical at today’s scale. This means that real applications will be relying upon public API endpoints. The recent EOS Token Distribution application was sufficiently demanding to shut down all available public API endpoints.  

The threat of government shutdown is based primarily on an assumption of illegal activity. We believe that there is a blue ocean of opportunities for legal blockchain applications that do not need to worry about a coordinated international effort to shut them down. Block producers and API endpoints can be setup in the most free jurisdictions 

## Conclusion 

EOS is designed around far more realistic assumptions and logic and achieves scalability by avoiding the dogmatic fallacies promoted by Bitcoin and Ethereum maximalists. I have shown time and again that DPOS is more decentralized in practice by any real measure of decentralization. I have also shown that there are more options for light clients and that Vitalik’s claims of government resistance ignore fundamental properties and vulnerabilities of any public blockchain. 


For those interested in the topic of decentralization you should read these blog posts of mine:

- [Decentralization of Nxt vs BitShares](http://bytemaster.github.io/article/2015/01/13/Decentralization-of-Nxt-vs-BitShares/)
- [Decentralization, Scalability, and Fault Tolerance of Bitcoin]( http://bytemaster.github.io/article/2015/01/12/Decentralization-Scalability-and-Fault-Tolerance-of-Bitcoin/)
- [How to Measure the Decentralization of Bitcoin](http://bytemaster.github.io/article/2015/01/09/How-to-Measure-the-Decentralization-of-Bitcoin/)
- [The Most Decentralized Proof of Stake System](http://bytemaster.github.io/article/2015/01/07/The-Most-Decentralized-Proof-of-Stake-System/)