ScalingNOW! — Scaling Solution Summit Summary

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.
• When: 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.
• 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.
• When: 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.
• 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:

1. open channel,
2. lock funds,
3. play game,
4. 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.
• 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.
• 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.
• When: No indication yet. Only just put an idea together about a month ago.
• Security: 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.
• When: 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.
• 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
• When: 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.
• Useability: 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 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.
• 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.
• 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.
• 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.
• 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.
• Security: Cosmos will offer 3 different types of chains: (1) sovereign, (2) hosted, and (3) hybrid (similar to Plasma).

1. Sovereign blockchains are fully independent and have their own validators (to find consensus), but can be bridged.
2. Hosted don’t have their own consensus mechanism.
3. 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.
• When: 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.
• 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.

1. Computational layer (bottom): WASM VM running off and on chain. There is an expectation that this will be able to work with Polkadot.
2. Dispute resolution (verification game).
3. 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.

• Security: Just need a single honest verifier: as long as one person checks work of solver they’ll prove the incorrectness. It is possible to delay execution of task by challenging it at the cost of a deposit (submit bogus challenges, at every turn you lose your deposit). Note that dispute resolution is done via Ethereum. There could be an availability issue as data is on IFPS which must be live with the published data also being live.
• Useability: Any application on ethereum can use TrueBit, ideal for those applications which can’t fit into gas limit. The cost of running an application on TrueBit = TrueBit gas cost * number of the steps to run on TrueBit.
• The ether gas cost: verification game is log(n); N is the no of steps in computation.
• Log(n): This assumes a binary search and take the midpoint.
• For some simple computations using Ethereum is faster, but past the crossover point it is faster to offload the computation to TrueBit.
• State channels can be implemented in the future which would help to speed up the verification game process.
• The team have a desire to all the task giver to have as easy a time as possible and to let them pay using any token. This is a problem which can be solved by decentralised exchange.

We wish to extend our thanks to the @Giveth team for helping to co-organise this event with us @Web3Foundation. The benefits of this workshop are immediately obvious in the feedback we received for teams and we are pleased to announce that we are already in the process of organising another event this year.

About us

The Web3 Foundation nurtures and stewards technologies and applications in the fields of decentralized web software protocols, particularly those which utilize modern cryptographic methods to safeguard decentralization, to the benefit and for the stability of the Web3 ecosystem.

Please follow us on Medium, on Twitter, and join us in our Riot channel to discuss this article or anything else related to Web3.

Join us on Riot: https://riot.im/app/#/room/#web3foundation:matrix.org

Twitter: https://twitter.com/web3foundation

Medium: https://medium.com/@web3

Giveth is re-engineering charitable giving, by creating an entirely free, and open-source platform, built on the Ethereum Blockchain. Our system cuts out bureaucracy and enables nonprofits to create a high level of transparency and accountability towards Givers. At any point until the moment funds are locked, a Giver can decide to withdraw them.

Please follow us on Medium, on Twitter, and join us in our Riot channel to discuss this article or anything else related to Giveth.

Join us on Riot: https://giveth.io/join/

Twitter: https://twitter.com/Givethio

Medium: https://medium.com/giveth