On the Origin of EOS
This article is part of the ongoing “Origin” series that tracks the emergence and evolution of projects in the cryptocurrency-based smart contract ecosystem. Today we’ll look at EOS and how it could threaten to supplant Ethereum as the dominant smart contracts platform.
EOS is a blockchain-based smart contract platform that promises great advances in addressing some of the key challenges in current blockchain technology: performance, user experience, and governance. Currently EOS is still undergoing development; there is no public blockchain on which to build and deploy applications. However, the ideas behind EOS are based on years of practical experience implementing the Bitshares and Steem platforms and the project is well funded.
EOS has been called an “Ethereum Killer” based on claims of high transaction throughput, zero fee transactions, and structured governance. Any one of these could potentially disrupt Ethereum’s incumbency as dominant smart contract platform, so let’s take a deeper look at each.
Transaction Throughput
EOS promises to achieve orders of magnitude performance improvements over Ethereum by implementing a number of scaling techniques, such as Delegated Proof of Stake (DPoS), parallel execution, partial evaluation and other optimizations. Similar improvements are also being researched and developed in the Ethereum ecosystem, allowing for a direct comparison of each project’s current approach, though both are likely to change as research progresses.
Despite sounding like similar technology, EOS’s DPoS has little in common with Ethereum’s proposed Casper The Friendly Ghost (TFG) protocol. In EOS’s DPoS a set of 21 elected block producers take turns in creating blocks with very high throughput. Producers who do not perform or misbehave can be voted out of their lucrative positions. In Casper TFG, anyone willing to deposit ETH can participate in the consensus mechanism and malicious/faulty activity is penalized by loss of deposit.
DPoS consensus works well in a consortium model, where a high degree of trust must be placed in a very small group of block producers. EOS’s viability as a public blockchain will depend on whether malicious/faulty producers can be promptly removed by a decentralized voting process. To achieve this EOS will have to overcome several challenges associated with stakeholder voting such as low voter participation, insufficient individual incentivization, difficulty of voters staying informed, and centralization of voting power (in whales and exchanges).
EOS hopes to significantly improve throughput by using parallel execution in the production of blocks. The primary purpose of block production is to provide a total ordering of transactions, which must be executed sequentially, but transactions which do not affect the same accounts can be executed in parallel. The EOS white paper describes a method of breaking blocks into threads that can run in parallel but lacks details on how the determination of transaction independence can be accomplished. EOS has announced that it’s parallel execution engine will be complete by June 2018. Ethereum’s EIP 648 describes a mechanism for parallelizing transaction processing that works in the existing block structure. It’s likely both platforms will eventually have parallel execution but not clear which will be first or whether one will provide a significant performance benefit over the other.
In theory, significant scaling can be achieved by having nodes only validate a subset of transactions rather than the entire blockchain. In practice it’s difficult to implement. The EOS white paper describes the benefit and challenges of partial evaluation, but presents no details for an implementation. In Ethereum, a great deal of research has gone into sharding (summarized here) but a working solution is not on the near term horizon. It’s possible the EOS could leverage the work done in Ethereum to deliver an implementation on its brand new platform first, or that Ethereum could use lessons learned from EOS’s implementation to speed up their deployment, though it may be years before either of these happens.
The use of Web Assembly instruction set provides performance benefits by allowing pre-compiled contracts to execute at near native speeds. The EOS virtual machine will be based on Web Assembly, while the Ethereum Flavored Web Assembly (eWASM) project is looking into replacing the existing EVM in a manner compatible with existing smart contracts.
In the race for higher transaction throughput, building an EVM and blockchain from scratch without billions of dollars at risk in existing contracts gives EOS an innovative advantage. Whereas Ethereum is applying rigorous theoretical validation and cautiously phasing in its PoS implementation, EOS is moving quickly to roll out a repackage of the existing Bitshares DPoS implementation. If Ethereum cannot keep pace, it may lose application market share to EOS, but as the value of the EOS network increases it will likely attract new kinds of attacks. Successful exploitation of a vulnerability introduced at any weak point in EOS’s high-performance design could be devastating. It remains to be seen whether DPos as implemented in EOS will be resistant to censorship, denial of service (DoS), and other collusion attacks when there is significant value at stake. If stakeholder voting mechanisms work well enough to successfully stave off attacks, EOS’s performance advantage could pose a credible threat to Ethereum’s dominance.
Zero Fee Transactions
Both EOS and Ethereum transactions are powered by tokens held by users. In EOS users get transaction allocations by making deposits that are visible to block producers, whereas in Ethereum users pay the producers (miners) directly via transaction fees.
EOS promotes a zero fee transactions model based on the philosophy that service providers (i.e. the smart contracts) will be able to monetize users and will therefore be motivated subsidize the required deposits. This is based on a common web app model where users receive service for “free” — i.e. in exchange for their personal data, attention to ads, etc. However, transaction fees make spam and DoS attacks expensive to carry out; without them smart contracts and blockchains are vulnerable to these kinds of attacks. Even with fees, such attacks have occurred on Ethereum, requiring hard forks with price changes to make them more expensive.
EOS tries to address spam/DoS issues by using a dynamic fractional reserve system for allocating transaction bandwidth to users. The idea is that block producers allocate transaction bandwidth to users proportional to the balance of their token deposits and depending on how congested the network is at the time. Attacks are defended by dynamically tightening reserves and thereby increasing the overall cost of the attack. This reactionary defense approach stands in contrast to Ethereum’s preventive approach of using transaction fees to set the price of an attack a priori.
Zero fee transactions could provide EOS some advantage over existing Ethereum contracts if the dynamic fractional reserve defense will secure them with significant value at stake. If zero fees win out, Ethereum dApps could remain competitive by implementing transaction fee refunds to users or taking advantage of mechanisms proposed in the upcoming Constantinople upgrade to allow contracts to pay for gas. If it turns out that transaction fees are necessary for certain types of contracts, then the flexibility to support either model on a per-application basis gives Ethereum the advantage.
Structured Governance
Ethereum is modeled after Bitcoin’s governance structure, in which the balance of power is distributed among developers, miners, and users. Evolution of the protocol is governed through a community driven process based on Ethereum Improvement Proposals but some capacity parameters (e.g. block gas limit) can be adjusted dynamically by miners of blocks.
Ethereum’s governance process was tested in the wake of the DAO hack, where nearly 15% of all ETH in existence was stolen. A hard fork to restore funds was proposed by a small group of thought leaders and supported by the majority of the community, but resulted in a community split where an opposed minority continued supporting the non-forked chain, now called Ethereum Classic. Such splits are believed to reduce the security and network value of the respective communities so there is interest in more structured governance mechanisms that can resolve issues without causing splits. There are proposals in the Ethereum community for some additional on-chain governance mechanisms, but no formalized structure has been put in place.
In contrast, the EOS white paper describes some formal and powerful governance mechanisms built into the protocol. In EOS, block producers finalize the transaction ledger and, as elected representatives of users, also carry out certain governance functions. A majority (17/21 or roughly 80%) of elected block producers can freeze accounts, update code in defective smart contracts, and enact hard forks. These actions can be an effective defense against obvious theft or malfunction if the power vested in the small group of block producers is not abused.
As the Ethereum community split showed, what constitutes theft or malfunction is more subjective than obvious, but by employing voting and majority rules, EOS hopes to systematically act in the interests of a large majority. However, it’s not clear that users would be happier giving censorship authority to delegates they elect by vote or that this structure would necessarily prevent an opposing minority from splitting due to actions taken by the majority.
Conclusion
EOS addresses some key challenges faced by Ethereum with various scaling improvements, new fee models, and formalized governance processes. This is achieved by granting significant powers to elected delegates and putting in place reactive security mechanisms that require increased trust in those delegates. A fundamental assumption is that users will actively exercise their voting power to prevent abuse of that trust.
If these mechanisms work well enough to defend the network when considerable value is at risk, EOS can deliver major advances in scalability, governance, and usability of decentralized blockchains. If not, EOS could become a public blockchain controlled by a wealthy cartel and/or experience exploits that destroy confidence in the platform.
The smart contract breaches that occurred in Ethereum remind us that transaction throughput and features are secondary concerns to bugs that allow the funds in an account to be drained. The biggest threat to Ethereum’s dominance right now is the vulnerability of its smart contracts. Any platform that delivers significantly better smart contract security before Ethereum can improve has an excellent shot at becoming dominant.
EOS is not that platform. The decision to implement smart contracts in general purpose languages such C++ and Javascript exemplifies a design focus that favors performance and features over security. In contrast to the safety and liveness proofs, costs of attack, failure thresholds, and other indicators of rigorous security engineering found in Ethereum research, the EOS literature to date consists mostly of handwavy claims that proposed mechanisms that will just “work” with no analysis of the conditions under which they won’t. With time and funding this situation could change, and EOS could publish more detailed analyses of the costs, limits, and effectiveness of its security mechanisms. However, there is no evidence at present to suggest such a shift in design priorities is taking place. Until it does, EOS runs the risk of its limits being discovered empirically through exploits, and failing to beat Ethereum at what matters most in a smart contract platform.
Dominance threat levels are explained in the introduction to the series. Below is a brief legend.
If you’d like to support this series with an ETH donation, please send it to 0x7e83982eb92502ad5d38c400ba2af7b135469ac9
Your support allows and encourages me to devote more time to these articles and is greatly appreciated.
