Night mode
Technical Quality Assesment of Cryptocurrencies: EOS
This report presents a methodology and template for the technical assessment of distributed ledger projects, in particular in what refers to their algorithmic and coding quality.
Table of contents:

1. Introduction

2. Scalability Approach

3. Development Environment

4. Consensus mechanism 

5. To sum up


EOS is a blockchain-based smart-contract platform which its founders describe by analogy to a (distributed) operating system. EOS is on track to become one of the biggest, if not the biggest, crowd-funded project in history (its ICO is still open until July 1st 2018). On top of the ICO proceeds, which are intended for the development, ecosystem and marketing promotion, EOS founders will keep a founders' share of 10% of the tokens.

Scalability approach 

EOS main appeal consists in its fundamental, low-level approach to massive scalability by means of side-chains and sharding. EOS proposes to orchestrate these in a strictly structured way, which they describe by analogy to a "Constitution" that is open to amendment by a qualified majority of stakeholders. That main basic orchestrator is a means for exchange of messages that encode instructions, called "actions", on the side chains. It is proposed a specialization of these so that ones could focus on threaded execution, and others on storage, which emphasizes the operating system analogy. Its smart-contract language of choice is a Turing-complete generic language, WASM, or Web Assembly, not a custom-built one. Also at the integral level, there is the definition of the permissioning system; it defines key ownership, vesting restrictions, signatures, revokability and delegation, not much differently than what is done on Bitshares or Steem.

This convoluted structuration is meant to overcome many of the shortcomings and limitations observed in practice in Ethereum, and it seems to have a much bolder emphasis on the scalability side of the decentralization - scalability trade-off (something that is described by Nick Szabo as the "social scalability" - "technical scalability" trade-off).

Development environment

EOS is being developed in a rather open way, with contributions of many developers. Its Github page:

Code is primarily written in C++14 and requires Clang-LLVM for compilation.  These numbers are rather impressive for a crypto-coin project. They are fairly comparable to those of  Ethereum (e.g, its reference Parity code has 120 contributors, 300 GH-watchers, 4000 GH-stars and  800 GH-forks) and probably surpassed in a strongly significant way only by Bitcoin (500 contributors,  3,000 GH-watchers, 30,000 GH-stars and 18,000 GH-forks).  Grey points and red flags: The Github project lists no public members.  Releases are unsigned, neither internally by Github account nor by PGP. It is true that the main-net release, where the real money will get involved, is still far away (scheduled late 2018), but a hacking event could still do much significant financial harm, notably by malware capable of stealing funds in wallets from other cryptocurrencies that the user might have installed in his system. 

Consensus mechanism 

EOS token holders can vote for a reduced set of 21 selected nodes called delegates. These 
delegates produce linked blocks sequentially, and they are also supposed to validate and sign each other's blocks.  Delegates choose themselves which block reward they are entitled to, by majority vote, and which block-validity consensus rules, by qualified majority vote. EOS authors call this method " delegated proof of stake" because of its high-level similarity with proof of stake systems (where fresh issuance is primarily allocated to the richest stakeholders), and even though the detailed mechanisms are fully different from those of proof of stake consensus techniques or from dynamical-membership multi-signature schemes.  

There is a hard issuance cap of 5% permanent inflation. Delegates can, in principle, by 
a simple majority, reduce that. It is hard to imagine a scenario where they would rationally propose that, though maybe that could happen if proposed competing delegate applicants can make convincing promises to vote for less and that creates a reputational damage to incumbent nodes voting for more to the point that it influences transactors' votes.

Transactions have a zero price and carry no intrinsical fee (but there is no way to prevent out-of-band fees). Spam prevention is supposed to be externally handled by delegates. A group of as few as 7 spam-friendly delegates (out of the 21 delegates) can flood-spam the network, at least until they get voted out. Bad actors (as decided by majority) can be not only censored but fully frozen, without any need of formal hardfork in the chain. The system offers no strong consensus guarantee against block invalidity: A simple majority of delegates can always ignore blocks by a disagreeing minority, thus turning it into the qualified majority that changes validity rules.

On top of this, the sidechains are validated at SPV (simplified 
payment verification) security, which implies that it is only header chains, not the entire blocks, that need to be validated.  In consequence, it apparently makes little sense to run a node that is not a delegate. The system looks equivalent for most practical purposes to a 21-member federation, however dynamically amendable in principle, which are supposed to be reputable, identifiable, independent (not anonymous, nor pseudonymous) entities. 

To sum up

This design is indeed very well scalable, at a fully different level above Ethereum. Development 
is professional and robust. Most issues that may appear are expected to arise because of incentive alignment and global governance issues, but not because of technological design limitations, as it is the case with Ethereum (whose design defects make it require constant amendment and realignment hardforks). On the other hand, EOS will have practically none of the (already timid) decentralized - or "socially scalable" - quality of Ethereum, which may be a flaw that proves significant in the long run.

Read more
5 / 5
5 / 5
4 / 5
4 / 5
5 / 5
5 / 5
You must login to be able to rate this report.
Overall score
Total votes: 9