The two-day ScalingNOW! workshop in Barcelona brought many teams together from across the blockchain space and from around the globe to share their ideas on scaling solutions. Once the teams touched down on Sunday night, the discussions began over the welcome dinner and it was clear that everyone was excited to get cracking.

In addition to this blog post we have created a detailed spreadsheet of the scaling solutions that presented at the workshop:

Scaling Solution Summary Spreadsheet

In this post, we will recap our findings from the first day of the event. We will briefly cover the purpose of the event, what scalability means, the leading solutions to scalability in the near term and some of our thoughts on the current state of the solutions.

The Objective

Pre-conference multi-team dinner!

We believe that in the current ecosystem “scalability is still the key obstacle facing blockchain”. Teams around the world are building scaling solutions, but until now they have been working in moderate isolation without much cross-team collaboration.

The ScalingNOW! event was also an opportunity for those teams working on scaling solutions to meet each other as well as meeting the DApp developers (on day 2) affected by high fees. To be invited, teams needed to be working on a scaling a solution meant for deployment either now or in the next few months.

This topic is extremely significant for the Web3 Foundation because both long and short term scaling solutions are necessary in order for the Foundation’s vision to materialise.

In the short term we can solve some of the scalability issues with a Proof of Authority (POA) side chain which can be linked to Ethereum via a bridge. Parity Technologies presented Parity Bridge and discussed how it can utilise low-cost POA networks to mitigate high fees. While this helps in the short term, the bridge is also one of the core elements of Polkadot (a longer term scaling solution stewarded by the Web3 Foundation).

What is scalability?

In the context of Ethereum, we define scalability as the capacity of the main network to improve performance (throughput, latency) as the number of users (DApps) increases, without making a difference to the users’ experience (gas prices, transaction times). The network architecture must be able to adapt to new demands as adoption increases, not the other way around.

We saw the scaling issue most clearly when CryptoKitties hit peak activity. Transactions on Ethereum quickly became very expensive and the network slowed down.

Dieter Shirley, a developer from CryptoKitties stated that “70% of gas is being consumed on smart contracts and we aren’t optimised for that. Also, the model of storing everything forever just doesn’t scale.”

Main Solutions — State Channels and Sidechains

The two main solutions that are ready for use today are state channels and sidechains. These solutions move some of the transaction logic off-chain, but ultimately rely on the main chain for final settlement.

There was also an alternative solution presented by the TrueBit team (more details are given later in this piece).

State Channels provide a direct one-to-one interaction between two addresses (for example, two users). The bulk of the computation involved in the interactions between users are calculated and communicated off-chain in a cryptographically secure fashion; however, the final settlement of balances occur on the mainnet Ethereum chain.

Attendee projects: µRaiden, Counterfactual, FunFair, SpankChain, Decentraland.

Sidechains, also known as bridged chains or parachains, are chains that run in parallel to the main Ethereum chain. These chains will have their own consensus mechanism which does not have to be the same type of mechanism as deployed on Ethereum. For example, it is possible to have a Proof-of-Authority (PoA) or a Proof-of-Stake (PoS) sidechain. These chains are not fully independent but ultimately rely upon Ethereum for final settlement. However, they do provide for multiple users to temporarily interact with each other off-chain.

Attendee projects: Parity Technologies, POA Network, Cosmos, Plasma.

Timeline

In order to help guide DApp developers we are providing the following timeline to show which scaling solutions are ready “NOW!” and which solutions will be ready in the near future.

NOW!

µRaiden — ERC20 & 223 State Channel.

Decentraland — Custom / Purpose-built State Channel.

Parity Tech — Sidechain Bridge.

POA Network — Sidechain solution.

< 4 months

FunFair — Generalised State Channel.

< 6 months

Cosmos — Sidechain solution (interoperating blockchains).

~ 6 months

Counterfactual — Generalised State Channel.

TrueBit — Off-chain solution for computationally-heavy DApps.

< 9 months

Plasma — Hierarchical Sidechain solution..

Project Summaries — State Channel Solutions

In this section we will summarise the key points regarding the state channel scaling solutions presented by those who visited Barcelona.

µRaiden

What : A state channel exclusively for tokens (only the ERC20 and ERC223 standards). If you want to use your own tokens you need to deploy your own contract.

: A state channel exclusively for tokens (only the ERC20 and ERC223 standards). If you want to use your own tokens you need to deploy your own contract. When : Ready!

: Ready! Security : Relies on the main chain to be secure, live, and useable. It is not possible to open more chains than main chain can handle. At the moment µRaiden doesn’t yet understand and obey whitelists or blacklists: this a problem when the channel closes.

: Relies on the main chain to be secure, live, and useable. It is not possible to open more chains than main chain can handle. At the moment µRaiden doesn’t yet understand and obey whitelists or blacklists: this a problem when the channel closes. In addition, users must keep private keys safe

Useability: A payment receiver has to run a light client or a full node as they need to check the transaction. The sender doesn’t need to do so since they are the ones who open the channel and knows its state. There is a gas cost of 100k to open the channel, but apparently less to close it.

Counterfactual

What : Looking into creating a generalised state channel beyond payments: the team suggested that their channels could be used for playing chess (with smart contract to mediate) or more generally as a means exchanging of information.

: Looking into creating a generalised state channel beyond payments: the team suggested that their channels could be used for playing chess (with smart contract to mediate) or more generally as a means exchanging of information. When : in 6 months.

: in 6 months. Security : Instant finality from the perspective of the state channel: i.e. the settlement of payment is instant, but only if the other party is available. This assumes the underlying chain is also live and secure. The only acknowledged attack on the state channel is if someone reports an out-of-date (old state) and then refuses to respond. If counterparty is cost minimising they can slow down transaction (DOS), which costs, but this doesn’t allow for stolen funds.

: Instant finality from the perspective of the state channel: i.e. the settlement of payment is instant, but only if the other party is available. This assumes the underlying chain is also live and secure. The only acknowledged attack on the state channel is if someone reports an out-of-date (old state) and then refuses to respond. If counterparty is cost minimising they can slow down transaction (DOS), which costs, but this doesn’t allow for stolen funds. Useability: Aiming to provide an API so developers don’t need to know exactly how their code works in order to use it. The use of state channels is suggested to provide response times seen with web applications; however, the team was keen point out that not all problems can be put into a channel (“not channeliseable”).

FunFair

What: Building a casino app which is directly P2P via a one-on-one state channel: i.e. a gambler vs a casino. FunFair are creating the app but will not act as the casino. Their state channel works in the following way:

open channel, lock funds, play game, close channel and release funds (settle balances).

FunFair said that their state channel is general and not just limited to payment transfers, but it has an off-chain state machine. They also stated that they developed a solution to create a shared random no scheme alongside state channel: this is to enable provable fairness.

When : Have launched an minimum viable product already, but expect more in 4 months. Code will eventually be published.

: Have launched an minimum viable product already, but expect more in 4 months. Code will eventually be published. Security : Lots of different things can go wrong. The games are web applications which can be vulnerable to the usual web security problems (this is off-chain); however, all transactions are signed as with regular Ethereum transactions, but users must manage own private keys.

: Lots of different things can go wrong. The games are web applications which can be vulnerable to the usual web security problems (this is off-chain); however, all transactions are signed as with regular Ethereum transactions, but users must manage own private keys. Useability: Opening a channel takes 15–20 seconds. The number of transactions is not capped by the FunFair state machine but by how many open connections Ethereum can handle.

SpankChain

What : Still at the early stages of thinking and planning out what their state channel solution will look like. Want to create a generalised state channel that does more than just payment.

: Still at the early stages of thinking and planning out what their state channel solution will look like. Want to create a generalised state channel that does more than just payment. When : No indication yet. Only just put an idea together about a month ago.

: No indication yet. Only just put an idea together about a month ago. Security : No indication yet.

: No indication yet. Useability: No indication yet.

Decentraland

What : The project is a virtual world where parcels of land have been sold. The auction already happened (December 2017) and was all off-chain.

: The project is a virtual world where parcels of land have been sold. The auction already happened (December 2017) and was all off-chain. When : Happened (December 2017, custom solution). New use-cases and solutions possible but no date indicated for completion.

: Happened (December 2017, custom solution). New use-cases and solutions possible but no date indicated for completion. Security : The auction had a trusted set up, but was fully verifiable. Some users ran scripts (off-chain) to validate that the state transitions were fully valid.

: The auction had a trusted set up, but was fully verifiable. Some users ran scripts (off-chain) to validate that the state transitions were fully valid. Useability: The solution was custom built for the Decentraland auction which means that a lot of work could be involved to adapt it to another project. It should be noted that the state transitions had to be completely serialisable which limits throughput: 10s-100s requests per second, and theoretical it could handle 1000s if is limited commitment failures.

General problems with state channels

Vulnerable to denial of service attacks

Ethereum must be deposited and locked-up while channel is in use

There is a challenge for application developers to change the way they design apps: they need to build with state channels in mind.

There is a dependency on multi-signature contracts. We’ve seen a range of attacks against these in the last year which highlights a potential risk if relied upon heavily. Hopefully, these become more robust over time.

Existing tools need to start integrating state channel functionality. Currently, limited progress has been made here.

Lack of a general timestamping service.

Not all applications are “channeliseable”.

State channels work in applications where you know the other parties in advance, although this isn’t strictly necessary it does invoke a certain amount of trust before creating the channel.

Project Summaries — Sidechain Solutions

Web3 Foundation Executive Director Peter Czaban presents to ScalingNOW!

In this section we will summarise the key points of the solutions who visited Barcelona and are working on a sidechain solution to scaling.

Parity Technologies

What : The team have created a bridge contract that can connect a POA network and the main Ethereum blockchain. The current test bridge allows transfers of ERC20 tokens, but the team are working on a generalised bridge that allows for arbitrary message passing. This is a test of the technology which be used to connect chains together Polkadot, naturally the Web3 Foundation is supportive of this technology

: The team have created a bridge contract that can connect a POA network and the main Ethereum blockchain. The current test bridge allows transfers of ERC20 tokens, but the team are working on a generalised bridge that allows for arbitrary message passing. This is a test of the technology which be used to connect chains together Polkadot, naturally the Web3 Foundation is supportive of this technology When : ERC20 test bridge is ready. A general bridge with arbitrary message passing is expected to be 2 months away.

: ERC20 test bridge is ready. A general bridge with arbitrary message passing is expected to be 2 months away. Security : If a majority of authorities is compromised then the bridge is compromised. This solution currently requires trust that a majority of authorities doesn’t collude. Authorities have their reputation at stake.

: If a majority of authorities is compromised then the bridge is compromised. This solution currently requires trust that a majority of authorities doesn’t collude. Authorities have their reputation at stake. Useability : Can deploy a dapp on the test net and then use exact same dapp on the mainnet. The code is the same.

: Can deploy a dapp on the test net and then use exact same dapp on the mainnet. The code is the same. Cross-chain transaction speeds are limited by the slowest chain; while the sidechain can be faster than the Ethereum mainnet, this solution doesn’t allow for the same throughput rates as state channels. Message passing in both directions should be less than 100000 gas each direction.

POA Network

What : The team have created a Proof-of-Authority (POA) Network which is a public Ethereum sidechain that uses a POA consensus mechanism with independent validators. It relies upon the Parity Bridge.

: The team have created a Proof-of-Authority (POA) Network which is a public Ethereum sidechain that uses a POA consensus mechanism with independent validators. It relies upon the Parity Bridge. The POA Network team are also working on an open source block explorer which is a valuable resource for the community.

The team have also created a deployment playbook for people to spin up a POA network quickly. This allows for a horizontal scaling using parity bridges.

When : Now! Deployment tools also exist.

: Now! Deployment tools also exist. Security : The considerations are similar to those of Parity (previous solution). There is a dynamic list of validators that vote to add / remove each other. Need to compromise 51% to compromise finality.

: The considerations are similar to those of Parity (previous solution). There is a dynamic list of validators that vote to add / remove each other. Need to compromise 51% to compromise finality. Useability : Writing a DApp for the POA network is the same for Ethereum: they are just solidity contracts (No new SDKs). There are some new security design considerations plus there is some set up involved, but the team have created playbooks to help developers get up and running.

: Writing a DApp for the POA network is the same for Ethereum: they are just solidity contracts (No new SDKs). There are some new security design considerations plus there is some set up involved, but the team have created playbooks to help developers get up and running. Block times are about 5 seconds (which allows for 3x throughput compared to Ethereum).

Cosmos

What : The Cosmos team are working on 3 different areas to improve scaling: (1) consensus algorithm, (2) state machine, (3) multiple interoperating chains.

: The Cosmos team are working on 3 different areas to improve scaling: (1) consensus algorithm, (2) state machine, (3) multiple interoperating chains. 1. Tendermint — is an asynchronous POS algorithm which provides Byzantine Fault Tolerance. It is suggested to be faster than synchronous POS without suffering other security issues.

2. A new state machine being developed by the team which is not Turing complete, but will allow for application-specific blockchains.

3. As there is a limit for a single blockchain there is a clear need a multi blockchain solution which allows for intercommunication.

When : (1) Tendermint core exists, (2) Cosmos SDK 99% done, (3) about 70% done so probably another 3–4 months away.

: (1) Tendermint core exists, (2) Cosmos SDK 99% done, (3) about 70% done so probably another 3–4 months away. Security: Cosmos will offer 3 different types of chains: (1) sovereign, (2) hosted, and (3) hybrid (similar to Plasma).

Sovereign blockchains are fully independent and have their own validators (to find consensus), but can be bridged. Hosted don’t have their own consensus mechanism. Hybrid chains have their own validators, but absorb some security properties form the Cosmos hub (a set of 100 validators).

There is finality in 1 block using tendermint; however, there can be liveness issues, if more than a third of validators go offline. In that case the network halts (fail safe).

Useability: The Cosmos team believe that Tendermint scales well. The Ethereum specific version of their algorithm (Ethermint) can do 200/300 txs per second and they hope their Cosmos SDK will improve that. If Geth does 200/300, It was guess that Parity can do 500. Not 1000s per second. The Hub has 1–3 second block times. It possible to have interoperability between Cosmos and Ethereum.

Plasma

What : Hierarchical sidechains on Ethereum. The aim is to move a lot of smart contract computation onto sidechains rather than being performed on the main chain.

: Hierarchical sidechains on Ethereum. The aim is to move a lot of smart contract computation onto sidechains rather than being performed on the main chain. When : Soon. For simple apps it could be done in a few months.

: Soon. For simple apps it could be done in a few months. Security : In simplest form: child chain with own consensus mechanism (POS). If that fails then fail back to root chain to settle. It’s the responsibility of everyone holding value on side chain to notice if something goes wrong, and to exit. There could be congestion if everyone tried to exit at the same time, and doubly bad if there was a busy ICO happening at the same time. Ultimate finality is on the main chain.

: In simplest form: child chain with own consensus mechanism (POS). If that fails then fail back to root chain to settle. It’s the responsibility of everyone holding value on side chain to notice if something goes wrong, and to exit. There could be congestion if everyone tried to exit at the same time, and doubly bad if there was a busy ICO happening at the same time. Ultimate finality is on the main chain. Useability: Users will need to deposit and withdraw funds. The team expect transaction through to be an order of magnitude higher (10x) than is present with Ethereum.

General problems with sidechains

In a POA network you need to explicitly trust the authorities.

Tooling can be an issue, although at least one team (POA Network) is working on an open source block explorer.

Can’t offer transfers as quickly as state channels do (although allow for many-to-many transactions).

Dependent on the root chain for complete settlement.

Project Summaries — Alternative solutions

TrueBit

What: Allows for computation to be offloaded to an off-chain virtual machine, but there is a smart contract on-chain. Tasks are created through the TrueBit contract, but clients pick them off and run them. There are three layers in the TrueBit solution.

Computational layer (bottom): WASM VM running off and on chain. There is an expectation that this will be able to work with Polkadot. Dispute resolution (verification game). Incentives (top): determines how much original task paid, how solver and challenger selected.

When:

Bottom: Computation layer: 6 months.

Middle: Verification game. 6 months.

Top: Incentive layer. Never? It evolves.