About the author

Keerthi Nelaturi

A Blockchain Researcher and Developer for ScotiaBank with a deep technical background. She has an MSc in Comp Sci and decades of development experience.

EOS Crypto – A Blockchain Operating System

By Keerthi Nelaturi / February 24, 2018

Until recently, most blockchain implementations targeting cryptocurrencies have been using Proof of Work (POW) as a method of consensus. However, PoW's issues surrounding scalability and extravagant usage of computational resources have people looking toward another method of consensus - Proof of Stake (POS)

Proof of Stake (POS) is taking precedence over POW, and the EOS blockchain is making use of a variation of POS - Delegated Proof of Stake (DPOS). In this post, we discuss features of EOS & DPOS and how it would lead to a better industry of blockchain applications.

To start with, EOS is not a blockchain. It is a blockchain operating system. That specification alone changes a lot of things. Ethereum, for example, is like a computing resource by itself with inclusion of EVM (Ethereum Virtual Machine) on every node that wants to participate in the network.

As a blockchain operating system, EOS would host, facilitate and govern any applications that are built on top of it like any other operating system we have ever had. EOS guarantees two main features that have been pain points for a lot of blockchain systems. They are:


Delegated Proof of Stake (DPOS)

Before we jump into the features, let's understand POS & DPOS. In POS, we have validators instead of “miners” and all mining is done virtually. Validators lock up some of their coins as stake and start validating blocks. If the same block gets appended, then the validators get rewarded with value proportionate to their stake.

Delegated Proof of Stake (DPOS), takes a minor shift from POS.  Instead of “validators” we have “block producers”. To be specific, there are 21 block producers. These block producers are elected in a voting process by anyone who has tokens on a blockchain integrated with EOS.

Each block producer will be given the opportunity to produce blocks proportional to the votes received. For a transaction to be confirmed we just need to wait for 2/3rd majority, which is 15/21 votes. This would take 1.5 seconds approximately. Hence, a 3 second block time has been guaranteed with this mechanism. Internal attacks stirred up by any block producer will be impeded by down voting that block producer and choosing a new replacement for the same.

8 Major Features of EOS

Feature 1: Vertical & Horizontal Scaling

Blockchain is no more the "newbie". Its success and longevity will depend on its ability to support real world applications. Scalability is going to be the reason why many of the current blockchain implementations will fail. As time goes, POW systems would incur high transaction fees and low throughput. EOS is tackling this problem. They support both, horizontal and vertical scaling.

  • Horizontal scaling includes support for parallel processing of smart contracts.
  • Vertical scaling includes transactions processed for second

Feature 2: Easy Maintenance

In EOS, any issue with a node/faulty DAPPs (Decentralized Application) can be mitigated by freezing that specific block producer or account. Other non-faulty block producers have the ability to freeze such accounts. They can also reject transactions based on computational cost. Transactions that take too much time and resources to execute would not be accepted by most other block producers. This enables EOS to eliminate the use of additional parameters, like "gas" in Ethereum.

Feature 3: Jurisdiction Rules

All transactions need to append a hash of constitution along with their signatures.

  • A Constitution is general jurisdiction rules agreed upon by all token holders within the EOS blockchain. This would enforce that all users of the application are bound to a specific governance.

Feature 4: Community Benefited Applications

An innovative idea by EOS - Users can elect 3 applications or smart contracts which would receive a configured percent of token supply per annum. These 3 applications can always be de-elected or elected again by the users.

Feature 5: Partial State Storage

EOS software allows any full node to run a subset of applications. This enables storing of partial state. Nodes maintain logs of all messages exchanged between accounts and applications. These logs are used to build states back in case of downtime.

Feature 6: Nil transaction fees

In general, users of blockchain applications are charged transaction fees due to the expensive resource utilization incurred in maintaining these applications. In EOS, bandwidth and resources are allocated depending on the tokens held by an application owner. Hence, it does not depend on the token value. This would promote new monetization techniques for the use of blockchain applications instead taxing users.

Feature 7: Ability to Rent Blockchain Bandwidth

Token holders can rent unconsumed bandwidth. This unconsumed bandwidth can then be allocated by block producers to other applications accordingly.

Feature 8: Interoperability

EOS is built to support multiple virtual machines. Currently, Web Assembly (WASM) and Ethereum Virtual Machine (EVM). This would enable anyone to run their smart contracts on other platforms like Ethereum or to communicate with applications on EOS seamlessly. This leads to inter blockchain communication.

Above is a list of the notable features of EOS. There are many other details on implementation that could be derived from their Technical Documentation.

Block.one is the core company responsible for developing EOS blockchain. Part of the team is Dan Larimar - famous for his contributions in BitShares and Steem platforms. EOS takes ideas from both platforms and puts them together.

3 Reasons Why Some Say "No" to EOS

  • Negative Coordination: EOS is extremely reliant on voting mechanism, which might get dissolved by many issues like:
    • Low vote count - Unless there are good number of nodes, malicious block producers can take hold of the blockchain.

    • Separation of interests - Token holder's interests might not be perfectly aligned with that of user's interests.
  • Inflexible Billing: All transactions are billed a fixed computational bandwidth irrespective of the time to execute.
  • Nothing At Stake Problem: Not a good way of solving "Nothing at stake" problem. The punishment for malicious utilization is just a down vote from being a block producer. They can participate again in the election process later on. A better solution to this problem would help mitigate malicious activity/utilization

Closing Thoughts

Ethereum, Waves, Cosmos (Tendermint) and Lisk are all competing technologies that are tackling the scalability issues in blockchain tech. 2018-19 is going to be a period of experimentation of scalability in the blockchain realm. We can’t be certain of who will come out ahead. But staying informed and keeping our eye on the ball will prove to be very useful (and potentially profitable).

Did you enjoy this post?

Help Us Keep Doing What We Do Best!

Tip Jar 🙂



Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

Continue reading >

Understanding Blockchain Tech – CAP Theorem

Blockchain technology has been around for a long time now.  It is a peer-peer, distributed and append-only database. In this discussion, we analyze the role CAP theorem plays in blockchain technology.

About CAP Theorem

CAP Theorem, also called as Brewer's Theorem proposed by Eric Brewer, identifies three specific system properties for any distributed/decentralized system. They are: Consistency, Availability and Partition Tolerance

  • CONSISTENCY -  Any read gives the latest write on the nodes.

  • AVAILABILITY -  At any point of time irrespective of whether the read is the latest write, client always gets a response without an error.

  • PARTITIONING -  In a distributed network of nodes, even though there is no possibility for the whole network to go down, there is possibility for partitions between nodes. This partition attributes to the delay or latency between nodes communicating in the network.
According to the CAP theorem, in any distributed network it is impossible to provide more than two of these three properties as a guaranteed feature
CAP theorem blockchain

Application of CAP Theorem in Blockchain Technology

Let's try and analyze blockchain in terms of its features and see if CAP Theorem applies to blockchain at all.

PartitionING is an inherent feature of any distributed system. That leaves us with only two choices to pick from: Consistency or availability

Scenario: Picking Availability over Consistency

If we pick Availability over Consistency in blockchain, any reads that happen are not guaranteed to be up-to-date. Although, there is a response from the network at all times, the purpose of the blockchain being a single source of truth is taken away.

On the other hand, lack of Consistency is something we simply can’t have in any monetary system. Consistency always takes priority in blockchain technology.

Say we consider Availability as an optional feature, This would force the network to be unavailable when there is a Partition – which would disrupt consensus. Hence, availability cannot be sacrificed in blockchain technology since consensus is key. 

Does That Mean Blockchain Violates CAP Theorem ?

Simply Put - NO, blockchain does not violate the CAP theorem

Those interested in blockchain, opt for AP (Availability + Partition) + Strong/Eventual Consistency.

Let’s consider Bitcoin – which uses Proof of Work as it’s consensus mechanism. Currently, bitcoin maintains a Read & Write protocol. The protocol is designed to consider the longest chain as the accepted main chain. A transaction is confirmed only if it is “X” number of blocks deep into the chain. Although a probabilistic model, it is left to the users to choose the value for X. Currently, for large transactions, a minimum of 6 blocks wait is considered a win. The same kind of protocol has been used in other blockchains as well Ex: Ethereum. There has been a lot of debate on whether to term this as strong or eventual consistency.

To summarize, configuring a client doesn't violate CAP theorem. It’s just a tradeoff between consistency and availability.

Get my upcoming eBook for Free!

"The Mango Guide TO Understanding Blockchain"

Offer Valid For FIRST 500 registrations only

Continue reading >
Join us on Telegram!