EOS Dawn 3.0: Scalability Review

 

Many of you have heard of Ethereum and it’s disruptive smart contract infrastructure.  You’ve also probably heard of its shortcomings regarding speed and scalability.  We have to give credit where credit is due.  Arguably the crypto landscape would not be where it is today without Ethereum and it’s ability to raise funds for alternative crypto projects through the ICO / ERC-20 Token process.  But here we are, and Ethereum is limited in what it can do. To bring cryptocurrency into the mainstream of application development we need a more powerful, flexible, scalable industry leader, and that’s where EOS comes into play.

EOS, or EOSIO, is a smart contract infrastructure that touts scalability, flexibility, and usability as its main drivers for success.  It is the brain child of blockchain veteran Dan Larimer, creator of legacy projects BitShares and Steem.  Written with Web Assembly in the C++ programming language, EOS offers an exciting alternative to Ethereuem’s dApp (decentralized Application) development.  We’ll get into the technical details in a bit but here’s the current snapshot of EOS relative to the whole crypto landscape:

Dawn 3.0 Technical Development Release

It may be hard to grasp the full potential of a project that doesn’t have a finished product yet and that’s why we’re diving deep into the latest development release of EOSIO called Dawn 3.0, specifically in regards to scalability and performance.  This release is highly technical and covers everything from network latency improvements to inter-blockchain communication.  If you’re curious about the technology here’s a quick breakdown of what Dawn 3.0 covered.

 

Goal: First feature complete pre-release of EOSIO with Developer API’s

**Upgrades to Scalability**

-DPOS/BFT Explanation

 

**Performance**

-Just-In-Time (JIT) vs Interpreter Compilation

-Resource Metering Rate Limiting

-Transactions Per Second Cases

 

**Inter-blockchain communication**

-Sparse Header Verification

-Context Free Actions / Inline Actions as Events

-Transaction Compression

 

**Contract Development / Support**

-BIOS Architecture

-Security Upgrades

-Transaction Proposal System

-C++ Standard Library Support 

-Automatic Scope Detection

 

**Roadmap to EOSIO 1.0**

-MultiIndex Database API Upgrades

-Stability

-Staking, Voting, Governance

 

Dawn 3.0: Upgrades To Scalability

Today we’re focusing exclusively on EOS’s scalability upgrades with Dawn 3.0.  When EOS comes up in conversation the first reference is very often related to transactions per second. I’ve heard anywhere for 50,000 TPS (Transactions per second) to a million for EOS!  Dawn 3.0 gave us some insights to actual test cases by the team, but to really understand what they mean and why TPS levels are significant you need to understand the underlying theory. Luckily for us, Dan Larimer provided a detailed overview of the inner-workings driving these claims.   A good place to start the TPS conversation is BFT DPOS. Huh? BFT = Byzantine Fault Tolerance and DPOS = Delegated Proof Of Stake.  Combined, these two theories house the core nature of EOS.  In short, a blockchain system that can achieve transaction irreversibility in the smallest amount of time is considered successful.  Better said, the whole idea is to minimize network latency (“the delay before the transfer of data initiates”).  To learn more about EOS’s BFT DPOS system watch Mr. Larimer in the videos below.

Got all that?  If not here are the highlights…

BFT Rule = no producer can sign the same block number twice (every block header has a block number, time, and previous block number that the producer signs).  If a bad actor signs two different blocks at the same number, that’s proof of Byzantine Failure.  (Larimer says to think of Byzantine Failure as two generals in a battle marching in separate directions) In order for this to create another chain, “fork”, the subsequent block producers would also have to sign these subsequent blocks two times and so on. If this occurs this is also a failure.  Smart contracts then take care of this arbitration to negatively impact and remove bad actors.   The likelihood of this crashing the entire EOS blockchain is almost non-existent as the system is setup to continue producing blocks with at least one node and the arbitration will automatically choose new, good-faith block producers to replace any bad actors in the network.

BFT DPOS (EOS):  With Dawn 3.0 the EOS blockchain is converting from a 3 second block producing interval to 0.5 seconds, thus reducing network latency.  In most blockchain networks, if Block B doesn’t receive the information from Block A in time then the network forks, slows down, or collapses (in severe cases).  With EOS, the handoff from Block A to Block B is so close together that even if some of the 0.5 blocks aren’t received it’s still possible to achieve the 2/3rd’s consensus needed for BFT in less time than the legacy systems like Bitshares, Steem, etc (which has 45s block intervals).  EOS also directly connects trusted block producers in the shortest distance around the globe  (~8ms per hop) to reduce latency even further.  Also, block producers can only censor transactions, not destroy the network, so this risk is mitigated and thus the EOS structure speeds up the overall network regardless of any “theoretical” risk that may exist.  Finally, there’s no financial incentive for influencing block production, but there is a disincentive in EOS.  All of the above lead to increased scalability and overall stability of the EOS blockchain over it’s competitors.  

Round Trip Communication (EOS) = 3 seconds

Round Trip Communication (Ethereum) = 9 minutes

Round Trip Communication (Bitcoin) = 3+ hours

Tendermint Example:  This example outlines what happens in Tendermint if the network suspects a bad actor… First there are several rounds of votes of what every node “thinks” they saw, which takes 2-3 seconds. If 1/3rd of them fail, all block production stops.  As stated above, in DPOS, as long as there is one honest node the block production continues.    Then once the nodes are replenished it requires 2/3rds to reach consensus irreversibility. Main takeaway:  In DPOS one person broadcasts the issue, everyone responds, and there is transaction irreversibility after one second in EOS.

 

Dawn 3.0: Performance

We briefly mentioned that EOS was written with Web Assembly and in this release it was revealed that the Binaryen interpreter would be used by default instead of the Just-In-Time Compiler.  Simply put, the JIT compiler offers the highest performance, while the Binaryen interpreter offers an increased level of stability.   The team doesn’t go into much detail here but states that the interpreter solves the issue of compiling new smart contracts and offers the ability to optimize performance in the background. Look for more detail on this leading up to the June release of EOSIO 1.0.

Another significant change in Dawn 3.0 can be seen in the hybrid resource rate limiting solution.  EOS will implement both an objective and subjective method to accomplish this critical step.  On a more abstract level, think about how important it is to optimize each node’s computational usage.  Unoptimized computational usage means a slow network, optimized means a high-performing network.  That’s exactly what the team is getting at here.  It is up to the block producers to manage both metering algorithms to produce the highest functioning blockchain.

Now to the fun part, TPS!  Everyone and their brother loves spouting off transactions per second benchmarks for their respective blockchain project.  With Dawn 3.0, the EOS team has laid out clear system performance tiers.

Worst Case = 1,000 TPS

-No Optimizations. Can achieve 1,000 TPS on multi-node network with the interpreter. Single-threaded signature verification

 

Average Case = 3,000 TPS

-Can achieve 3,000 TPS on multi-node network with the JIT compiler. Single-threaded signature verification

 

Best Case = 6,000 TPS

-Parallel Signature verification implemented but disabled, optimized resource rate limiting.

Can achieve 6,000 TPS on multi-node network with the JIT Compilier

 

Theoretical Case = 8,000 TPS

-Max CPU Capability scenario (no networking code), disabled Parallel Signature verification

Can achieve 8,000 TPS on multi-node network with the JIT Compilier

Can achieve 2,700 TPS with the interpreter

 

Parallel Chain Case  = UNLIMITED TPS

-Implement inter-blockchain communication to divide workload across as many blockchains as needed

-1000 parallel chains = Millions of TPS (untested)

 

Dawn 3.0: Wrap-up and Look Ahead

EOSIO made it very clear that their focus in this release of Dawn 3.0 was stability, while flashing insights into the potential of a broad, public, interconnected blockchain network.   The scalability outlined above will lead to exponential increases in the level of decentralized application (dApp) development in the second half of 2018.  User Interfaces can become much more responsive since irreversibility is achieved within one second with 99.9% certainty. The EOS blockchain will provide a platform for seamless dApp user experience and we expect to see this reflected in the project’s traded value as we march towards the June mainnet release of EOSIO 1.0! 

 

 

EOS Website : eos.io

EOS Whitepapergithub.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md


Jeff Wiand

Avid Blockchain and cryptocurrency investor. Co-Founder of SolveTheLedger, a blockchain/cryptocurrency market research site. Certified Patent Agent before the United States Patent and Trademark Office. Passion for software development, web development, social media, technical analysis, and building teams. Currently pursuing a Master's of Science Degree in Computer Science with concentrations in Artificial Intelligence and Distributed Systems from DePaul University in Chicago, IL. Earned a Bachelor's Degree focused in Mechanical Engineering from West Virginia University.

All author posts