Scaling The Ethereum DApp pt.1

Intro

TPS (Transactions Per Second) is the key performance measurement of any distributed system. Unfortunately, in its current state, Ethereum cannot handle large numbers of transactions:

“At the moment, Ethereum can handle about 13 transactions per second (TPS), which cuts in half to about 7 transactions per second for token transfers…”
(https://medium.com/@FEhrsam/scaling-ethereum-to-billions-of-users-f37d9f487db1)

This means that today you cannot easily write a DApp that can be used by millions of users simultaneously. We are building a tokenization platform that will be used by thousands of people at once, and we are very interested in analyzing how to design the app to allow this.

Of course, TPS cannot be used as a perfect “one and only” measure of the blockchain throughput, but we will use it in order to simplify everything.

This is the first article in a series in which we are going to explore the ways DApp can be scaled to millions of users.

Approaches to Scaling the Blockchain

There are various still-to-be-implemented approaches to scaling the blockchain that i have categorized as follows:

1. Improving the blockchain (low-level optimizations)

1. Change the consensus algorithms — migrate from PoW to PoS; make your blockchain more centralized or less secure to attacks, etc;
2. Parallel transaction processing;
3. Low-level code optimizations in the EVM (Ethereum Virtual Machine);
4. …

These optimizations can be combined, but even in the best case that only leads us to 10x-100x TPS improvement. Also, because we are not low-level core Ethereum developers, we can only sit and wait for improvements accomplished by others. That is why this approach is out of the scope of the current article.

2. Horizontal Scaling — Sharding (“Parallel blockchains”)

Please note that Horizontal/Vertical Scaling terms have nothing to do with well-known DB/server horizontal and vertical scaling. I propose these terms only by analogy.

https://www.coindesk.com/information/will-ethereum-scale/

The goal of sharding is to move away from requiring ‘full’ nodes — those which store the full state of the network and every transaction that occurs.

Instead, each node stores a subset of this data and only verifies those transactions. If a node needs to know about transactions or blocks that it doesn’t store, then it finds another node with the information it needs.

The problem here is that the process isn’t exactly trustless, since, in this model, nodes need to rely on other nodes.

https://blockgeeks.com/guides/what-are-ethereum-nodes-and-sharding/

Basically, instead of making 50 DApps run on one main blockchain, split it into (for example) 2 blockchains and run 25 DApps each. You can imagine geo-based sharding style:

1. Ethereum-USA;
2. Ethereum-Europe;
3. …

If you need to send some information from one shard to another — some cross-chain mechanism (call it “gateway” or “relay”) should be used.

There are some problems with this idea:

• Smaller chains can be attacked easier and are more vulnerable;
• There needs to be a coordination mechanism (low-level or high level) to know which node works with which shard;
• There needs to be some (low-level or high level) cross-chain interaction/incentive mechanism implemented.

Current state of Ethereum Sharding

https://github.com/ethereum/sharding/blob/develop/docs/doc.md

Introduction of sharding is currently split into 4 phases. In the first stage no any communication between shards will be possible.

First stage is still under the development and will require:

1. Implementation of a high-level PoS with stakes in the mainnet;
2. Changes to transaction format;
3. Some improvements like “account abstraction” (already released in Byzantium) and “account read/write list”;
4. Some user actions to switch from one shard to another. This can be automated. Anyway, modifications of client apps or DApps will be required;
5. …

It is not clear when and whether low-level sharding (i.e. included into the Ethereum protocol) will be implemented. During the first stages it will be implemented only as high-level solution (i.e. in the smart contracts) with some off-chain support.

When we will see Sharding (even stage1) implemented?

Vitalik Buterin went to state (Jan 2018) that the next phase of the four-stage scaling proposal will be completed in “a month and a bit”.

Here is another quote regarding the complete sharding solution: “With further design iterations, implementation, testing, etc. Ethereum won’t have sharding until late 2019 at the earliest.“

3. Homogeneous Vertical Scaling (“Plasma”)

Blockchains can be hierarchically arranged one on top of another or even in a trees. In its simplest form, two blockchains are used: root and child.

Mining is done with full security only on the lowest-level blockchain, with security and proofs flowing from the root. That will allow to create a well balanced system to maximize data availability/security and minimize costs.

“Plasma is a series of contracts which runs on top of a root blockchain (i.e. the Mainnet Ethereum blockchain). The root network contract processes only tiny amount of commitments from child blockchains that are able to do an incredibly large amount of computations in most cases. Commitments are broadcasted periodically to the root blockchain from the child. One can view the root blockchain as the Supreme Court from which all subordinate courts derive their power.”

Current state of Plasma

It is still in the early development stage.

Vitalik claims here that “Plasma could have been implemented on Frontier. The only reason it will take until after Metropolis launches is because Plasma implementations will take a while to actually write and test the code for”.

4. Heterogeneous Vertical Scaling (“Ligthning Network”)

This off-chain approach may be also called the “2nd-layer network”, “layer-2 solution”, “micropayment network”, “lighthning network”.

The basic idea is to switch from a model where all transactions hit the shared ledger on the blockchain (which is the bottleneck) to a model where users can privately exchange messages which sign the transfer of value. In short: “off-load some, but not all, transactions to the off-chain”.

Even if you send millions of transactions off-chain, your gas fees are still very low, because only a small number of on-chain transactions are needed to secure the settlement (say, you send tx to the chain once in 24h).

Off-chain transactions can be sent from one peer to another through the http web-sockets or tcp sockets. In reality, almost any medium can be used that provides a very high TPS.
Lightning Network is the BTC term. The Raiden Network implementation is very similar to the Lightning Network.

Current state of Ligthning Network (Raiden for Ethereum)

“µRaiden (read: Micro Raiden) is a payment channel framework for frequent, fast and free ERC20 token based micropayments between two parties. It comes as a set of open source libraries, documentation, and code examples for multiple use cases, ready to implement on the Ethereum mainnet. Whereas its big brother the Raiden Network aims to allow for multihop transfers via a network of bidirectional payment channels, µRaiden already enables to make micropayments through unidirectional payment channels.”

Using Raiden Network/Micro Raiden for the DApp state transfers is still limited.

5. Heterogeneous Interconnected Multichains (“Polkadot”)

Polkadot is another approach to scaling.

It is a protocol that allows independent blockchains to exchange information between each other. This allows to use high troughtput blockchains connected with a better security but slower blockchains.

Some use cases:

- An Ethereum smart contract transfers ZEC cryptocurrency to another Ethereum smart contract

- A private blockchain transaction which triggers another transaction on a global financial blockchain.

“Polkadot is a scalable heterogeneous multi-chain. This means that unlike previous blockchain implementations which have focused on providing a single chain of varying degrees of generality over potential applications, Polkadot itself is designed to provide no inherent application functionality at all. Rather, Polkadot provides the bedrock “relay-chain” upon which a large number of validatable, globally-coherent dynamic data-structures may be hosted side-by-side.”

In other words, Polkadot may be considered equivalent to a set of independent chains (e.g. the set containing Ethereum, Ethereum Classic, Namecoin and Bitcoin) except for two very important points:

• Pooled security;
• Trust-free interchain transactability.

These points are why we consider Polkadot to be “scalable”. In principle, a problem to be deployed on Polkadot may be substantially parallelised — scaled out — over a large number of parachains. Since all aspects of each parachain may be conducted in parallel by a different segment of the Polkadot network, the system has some ability to scale.

Polkadot is currently still in the development stage. We hope they will connect to the Ethereum blockchain soon, but we still can’t use it in production. There is no clear vision as to how the DApp would look and work in the Polkadot environment.

Resume

There are many similarities between the “Plasma” and the “Lightning” approaches.

It is worth noting that one of the core developers of Plasma is Joseph Poon, who co-authored Bitcoin’s Lightning whitepaper.

Approaches 2, 3 and 4:

1. may require changes to the Ethereum core and basic EVM structures;
2. requiring changes to the DApp design.

In the next article we will discuss and analyze the design approaches pertaining to the existing DApps. Many blockchain projects are trying to scale their DApps. Let’s see how they are doing.

Please stay tuned!