This spreadsheet shows a summary of scaling solutions presented on the first day of the ScalingNOW! workshop in Barcelona.
|Parity Tech||POA Network||Plasma||Diamond Drops||Cosmos||Polkadot||TrueBit|
|Link to project||https://raiden.network/micro.html||https://counterfactual.com/||https://funfair.io/||https://decentraland.org/||https://liquidity.network/||https://github.com/paritytech/parity-bridge||https://poa.network/||https://plasma.io/||https://github.com/Drops-of-Diamond/diamond_drops||http://cosmos.network/||https://polkadot.network||https://truebit.io/||Brought to you by||Riot||Medium|
|What is it?||Micropayments from one party to another (currently, ERC20 & 223).||Generalized state channels with modular functionality.||State channels (they call them "fate channels") that allow numerous transactions between player and casino. These are short-lived channels with proveable randomness.||The team want to help others build state channels. They created a custom solution for their own needs which involved an off-chain auction of land in a virtual world.||The Liquidity.Network is a practical global off-chain system to initiate and facilitate payments on the blockchain, currently built on and operational on Ethereum. The network provides off-chain payment hubs which are conceptually similar to P2P payment channel networks such as Lightning and Raiden.||The Parity bridge is an ongoing research solution to connect Polkadot later. You can use it to connect a POA network to a DApp.||POA Network took the Parity Bridge and enhanced it for useability. Developed a set of tools to deploy your own POA network with a Parity node and a governance system. Developed a UI. Working on an open-source blockchain explorer.||Hierarchical sidechains on Ethereum. The aim is to move a lot of smart contract computation on to sidechains rather than being performed on the main chain.||An Ethereum sharding implementation in Rust.||The team believe there's probably something in Cosmos for most DApps. 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.
|Polkadot is a heterogeneous multi‑chain technology. It consists of many parachains with potentially differing characteristics which can make it easier to achieve anonymity or formal verification. Transactions can be spread out across the chains, allowing many more to be processed in the same period of time. Polkadot ensures that each of these blockchains remains secure and that any dealings between the are faithfully executed. Specialised parachains called bridges can be created to link independent chains.||Allows for computation to be offloaded to an off-chain virtual machine (allows for computationally-heavy DApps), 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.
|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.||https://riot.im/app/#/room/#web3foundation:matrix.org||https://twitter.com/web3foundation||https://medium.com/@web3|
|1||Roadmap||Finished. Waiting on EIP standard.||August / Sept 2018||There is a live minimum viable product. Full solution is scheduled for May / June 2018.||Happened (December 2017, custom solution). New use-cases and solutions possible but no date indicated for completion.||MVP test in Q1 2018. Mainnet launch scheduled for Q2 2018. Also building an off-chain exchange which will be launched in Q3 2018.||Now! Using ERC20.||POA Network is available now. Cross-chain crowdsale is available now. We have a proof of concept bridge running now, so you can tokenize the native coin of your sidechain so you can connect your ERC20 to decentralized exchanges.||Soon. For simple apps it could be done in a few months. If someone began implementing now with some app-specific functionality they could have it working later in 2018.||Phase 1: July 2018. Shards without an EVM; blobs, proposers of blobs, blobs serialized into collations, notaries try to download collations and vote on them, and a committee accepts a collation as part of the blockchain if the collation has been included in a shard and more than 2/3 of the sampled notaries voted for it.|
Phase 2: ~May 2019, The EVM state transition function with EWasm; full nodes only; asynchronous cross-contract calls only; account abstraction; archive accumulators and storage rent.
Phase 3: October 2019: light client state protocol with executors and state minimized clients.
Phase 4: Feb 2020. Cross-shard contract calls with internally synchronous zones.
Phase 5: October 2020. Tight coupling with main chain security; Data availability proofs; Casper integration; Internally fork-free sharding; Manager shard.
Phase 6: October 2021. Super-quadratic sharding. Recursively, shards within shards within shards… Load balancing.
|Tendermint core is ready now. Cosmos SDK is in alpha. IBC is ~70% ready, hopefully by May / June 2018. Ethermint Sovereign will also be ready by May / June 2018, hosted chains 1 month after.||Proof-of-Concept 1: Now! (Q2 2018). Network launch: aiming for Q3 2019.||Bottom: Computation layer. c. August 2018.|
Middle: Verification game. c. August 2018.
Top: Incentive layer. Never? evolves.
|Giveth is re-engineering charitable giving, by creating an entirely free, 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.||https://giveth.io/join/||https://twitter.com/Givethio||https://medium.com/giveth|
|2||Security||Relies on main chain to be secure / live / useable. Users must protect private keys. By clogging up the chain, sender can steal funds sent from the receiver.||Being a counterparty to someone in a channel means you can slow them down by being unavailable. However, there is a price to disruption. The longer the period of unavailability, the higher cost: this is like an interest rate on capital for locking up capital. Finality is instant from the perspective of channel. Rely upon the underlying chain being live and secure.||All transactions are signed, so users need to keep their private keys secure. Two types of dispute: (1) invalid state transition (someone trying to cheat), (2) everything else can be reduced to a timeout. There is also web app compromise but that's off-chain.||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.||Liquidity's protocol is trustless and relies on the security of the underlying blockchain.||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.||You have to trust the validators. In order to say the network is compromised, it would be a 51% attack, so you would need to compromise 51%. POA Network developed a trustless ceremony process-master of ceremony has to distribute initial keys, trustless DApp to their own created keys. Another DApp where validators can vote with their voting keys to e.g., change the consensus threshold.||Child chains have their own consensus mechanisms, but also rely on the root chain: POS on child chain is first protector, but if that breaks you fall back to Ethereum main 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.
|Sharding is on-chain, so the developers believe this makes it inherently more secure than state channels or Plasma. Sharding can scale exponentially while maintaining security. Finality can be improved (e.g). with Casper and / or kept the same.||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): should allow for faster block times (1 - 3 second block times)
|The set of Validators provide security for the entire Polkadot network. Consensus requires at least 66% of Validators to come to consensus upon a given chain. Validators provide security for all “hosted” parachains as well as information sent to/from blockchains that bridge to the Polkadot Network. Parachains don’t need to provide their own security as they can benefit from the pooled security of all validator nodes||Just need a single honest verifier: as long as one person checks the 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.
Scope of applications
|Free, fast, and frequent token transfers for unidirectional payments (typically in many-to-one setups). Currently for ERC20 and ERC223. If you want to use your own tokens, you need to deploy your own contract.||Trying to provide generalised state channels for any smart contracts, not just payments, but there are some constraints. The app needs to be "channeliseable": must be able to enumerate and connect to counterparties. Trying to figure out N-party channels.||Anything that can run in a single Ethereum transaction (not just payments). Each transaction is a generalised state transition: as long as it can be done on-chain.||One-to-many applications, doesn't just need to be one-to-one.||Liquidity allows the fast, free and bi-directional transfer of Ether and ERC-20 tokens as well as the atomic swap of Ether and ERC-20 tokens.||Any DApp pretty much without modification. Can deploy a DApp on Kovan, POA, and try it out, test it out, and iterate it and use exactly the same DApp on the mainnet||Same as what Parity Tech offers.||Can build an app-specific sidechain or an app-specific function into the sidechain.||The first phase is abstract: enshrined-in-consensus data availability. So the scope of applications is broader than Ethereum 1.0, due to potentially exponential scalability.||Offer different apps is so you can choose the best use case for your DApp. Can build turing complete blockchains or not! In the Cosmos SDK, have an optional governance model, you can upgrade using governance. |
In the SDK, you define transaction types, you define different transaction types, the SDK handles all the state trees. Have access control mechanism.
|Applications can be written to run on one of the many parachains that support smart contracts within the Polkadot network. In addition, DApps can also leverage the features of other parachains or even create a new parachain. It will also be possible to run a DApp on any blockchain that offers smart contracts and bridging (e.g. Ethereum): this will allow for those DApps to interoperate with Polkadot.||Any application on ethereum can use TrueBit, ideal for those applications which can’t fit into gas limit. Must be okay with asynchronous callback. As the computation layer uses a Wasm VM then it should work well with EWasm and other Wasm projects (e.g. Polkadot).|
|4||Throughput||Underlying chain limits number of channels that can be opened/closed per unit time. In-channel throughput only limited by connection between sender and receiver, signature validation, etc.||Throughput should be high: primarily limited by things like signature validation.||Ethereum is main bottleneck: limited to 8 million gas, and reckon 100 players a minute could start a session. Sessions could last hundreds of thousands of hours.||State transitions had to be completely serialisable which limits throughput: 10s-100s requests per second, may be possible to see 1000s per second if there are not many commitment failures.||The number of open channels is not limited by the underlying blockchain, as opening a channel with a Liquidity hub is performed off-chain. Off-chain throughput transfer is limited by the network connection between participants and the respective crypto that is implemented.||Limited by the slowest chain (usually mainnet). The bridge processes themselves no problem handling the relay. On the POA side (the sidechain) you could have a much higher throughput than mainnet.||The same throughput as Parity. Transactions per second: 5 seconds block, 8 million gas limit. Gas is 21k, 76 transactions per second. You can also increase your block size on your own poa network if you want more gas limit.||An underestimate: 1 OOM, but team suggest it could be much higher.||With quadratic sharding (up until phase 5) there is a plan to have 100 shards: up to 100 fold increase in throughput, but minus extra overhead and latency. Hoping for an exponential increase in throughput with exponential sharding in phase 6.||Tendermint alone can scale very well. Ethermint can do 200-300 transactions per second. On a single laptop using Geth can get around 200-300 transactions per second, maybe 500 tps with Parity, but not 1000s tps.||Parallel execution in parachains should make it possible to execute orders of magnitude more transactions.||Scales as the TrueBit network grows. Tasks are created through the TrueBit contract, but clients pick them off and run them.|
|5||Latency||Near instant.||Finality should be instant if the counterparty is available. Note that both parties need to agree and sign on what the current state is. Ingress should be fast. Egress: is a normal transaction.||Once something is written to the chain it is final. Can open a channel with one transaction, and another transaction to end it. Opening a state channel takes 15 - 20 seconds.||Instant finality once submitted to multi sig / channel, however egress is very slow (after the entire auction had ended).||Depending on Internet connection and crypto computation, but essentially instant.||Low latency if sidechain is POA or POS. Mainnet transaction finality.||5 seconds/block which is fast if sidechain is POA or POS. Mainnet transaction finality. Initialization: deploy on two chains.||There can be a withdrawal latency which can be exascerabated if everyone tries to exit at the same time.||It depends, you can have heterogeneous sharding with low latency, but there is a tradeoff: decentralization vs throughput.||One block finality on Tendermint. If building a POA chain, use Ethermint because it does give the security guarantees and better finality. One possible drawback is liveness issues.|
Tendermint: if more than ⅓ goes offline, process halts.
|Aiming for low latency. There progressive consensus mechanism that combines BFT and Aurand. BFT ensures absolute finality every 5 blocks, while Aurand ensures good finality for the 4 blocks between. If more than ⅓ goes offline, process halts.||In cases where the solver tells the truth, you will receive a callback. Can't say the time for that. The Truebit verification games are perfect for a state channel. You could have instant finality between these, the final thing settles on chain. There's ways to make this shorter.|
|6||Bottlenecks||Opening / closing channels is limited by the chain (Ethereum).||Bottleneck is the underlying chain. Need guaranteed liveness.||Performance of EVM scales linearally. Blockchain gas limits. Although solution is lineraly scalable. Team can easily build 100 nodes and can provide regular web-like communication times.||The use of an off-chain database to hold the auction details.||Internet connection||The slowest part is the mainnet (Ethereum). Can get some additional speedup by having a lower amount of consensus on proof of authority chain. Compared to sharding or things like that, there's no curve that keeps going up.||Same as Parity.||Everyone exiting back to the root chain at the same time would create congestion (which could be compounded if there was increased activity, e.g. a popular ICO).||Computational resources are evenly reduced by dividing resources between shards: computation, I/O, storage and bandwidth. At the moment, I/O is the biggest bottleneck, so to reduce bottlenecks we will still need solutions other than sharding, but sharding will allow more rapid development in shards before they are merged on the main chain.||Bottlenecks is throughput of the signatures on peer-to-peer layer, a bottleneck on Cosmos is if you have many interchange transfers. |
The hub provides an efficient routing mechanism through blockchains, but ultimately the hub has a limit. The solution is multi-layer hubs.
|Transaction speed is likely limited by the slowest chain when performing a cross-chain transaction. Transactions on the same chain will be faster than cross-chain interactions.||The base chain is the bottleneck. The bottleneck is the amount of space available on the main chain.|
|7||Cost||100k gas cost to open, less to close. ERC20 is more expensive than ERC223. Instead of creating a new channel, deposits can be topped up or partially withdrawn if needed (saves gas).||No additional cost compared to an on-chain transaction. Note that smaller transactions cost less while large transactions cost more (could end up being cheaper to do the transaction on chain). Funds do need to be locked up though.||Ethereum gas and storage costs. Considering IFPS for storage.||One transaction for everyone. The team covered cost to send tokens back to the user.||No costs for channel opening, 50k gas to deposit Ether, 50k to withdraw Ether||200k gas to deposit and withdrawal (100k each). This assumes free transactions on the sidechain.||How you pay for transactions, would need to have a native coin on that network, its the same process on mainnet. Transaction costs 1 POA token.|
How much gas price depends which networks you want to connect. If the validators are running the bridge, you can specify which gas price will be used and how much time to take to mine the transaction on the mainnet.
|Funds are deposited through root chain into child chain: this costs gas. The funds are locked into the root chain, but then received and ready for use on the child chain. Withdrawing funds is another transaction on the root chain. While funds are locked they can't be used elsewhere (opportunity cost).||Gas costs should be reduced, but other solutions will be needed which are in the roadmap, e.g. storage rent and somehow internalizing the cost of bandwidth||Proof of Stake is not thought to be as expensive as Proof of Work, so fees ought to be lower.||For DApps / parachains: can be anything from simple gas metering like ethereum all the way to custom payment models where users do not pay.||The cost of running an application on TrueBit = TrueBit gas cost * number of the steps to run on TrueBit. Verification games have an ether gas cost which scales as log(n); N is the no of steps in computation.|
The reward that a task has attached to it, all have to scale with the complexity of the task. The reward has to make it worthwhile. For some simple computations using Ethereum is faster, but past the crossover point it is faster to offload the computation to TrueBit.
|8||Upgradeability||Solution is 'finished', but it should work with future technology such as Plasma and sharding.||As solution is off-chain it is so easy.||Planning an upgrade profile: should be transparent. The team are keeping an eye on future projects, but building on what’s available right now.||The solution was custom build for a specific purpose, but they are thinking of future directions: e.g. for voting.||Liquidity is agnostic to the underlying consensus mechanism (PoS, Plasma, Sharding).||Roadmap is for this to connect to Polkadot. There's also an upgrade path to Plasma.||You can design your smart contracts to be upgradeable. There are two sides, the rust side and the smart contract side. Rust side, is the same as having every single miner to upgrade to a certain version. It's the same way you can upgrade your system or set of validators that are running the bridges. Upgrading the Parity Bridge requires knowledge of Rust.|
DApp will be ready to move on to other things like sharding and Polkadot later.
|Can build in migration functionality into the root chain smart contract. If making a big change you should just create a new Plasma chain. For small changes you can do “soft forks” for an existing plasma chain.||Probably still need hard forks, but you could potentially abstract hard forks from the UI so that a user doesn't see them, just pauses when they happen.||On-chain governance to allow for upgradeability. Two upgradability modes:|
- Upgrade the underlying blockchain
- Ethermint - deploy new model of the smart contract
|One of the design features is that the network protocol can be easily upgraded without having to hard fork the Polkadot virtual machine (it is a WebAssembly virtual machine).||State channels can be implemented in the future which would help to speed up the verification game process. Should work well with other Wasm projects: e.g. EWasm and Polkadot.|
|10||User Experience||Can use the browser since the code is in JS also possible to interact with metamask. A receiving user has to run a light client or a full node. The sender doesnt need either: payment just going from sender to receiver. The senders just need to sign something by clicking a button, but be aware that the sender doesn't necessarily know what they are signing (will be fixed by EIP 712).||Response times comparable to web applications. Everything is parallel, so no cross depency: users are independent of each other.||Need to be able to make an ethereum transaction. Got a big onboarding process (e.g. need metamask installed). Need to be able wait 15 / 20 seconds to open a state channel.||The message sent to users sign was both computer readable and human readable.||MetaMask interaction is operational. User needs to be online to receive payment.||Users don't necessarily need to be aware that the bridge exists, except latencies. They interact with normal contracts. There is latency, there is some transparency issue we need to resolve where the bridge is down for some reason, a transaction will seem stuck, so it would be good to have Etherscan for the bridge, where it’s very transparent, where my relay actually is. Other than that, users have to use two networks. Ideally only when they use the bridge and move stuff over.||Every single wallet for Ethereum is supported natively, have support for MyEtherWallet and Metamask. The RPC node has to be trusted. Trustwallet works with POA Network.||Need to get used to depositing and withdrawing their funds, and to watching sidechains or using a trusted (and possibly incentivized) third party to do this.||UX can be customized with heterogeneous sharding (e.g. with abstraction of execution engines allowing for, say an execution engine for a specific high-volume dapp like Akasha); if we internalize any costs, there are solutions to make it easier for developers and users, e.g. layer 2 storage markets, pay-to-resurrect contracts, time-to-live, etc.||For Tendermint the best thing is that your action happened or didn't, fast finality that helps user experience. Hardest thing with the Cosmos is users need a good multi-chain wallet. Tendermint allows you to query into the state of a state machine you have on top.||The inherent scaling provided by Polkadot should help to make DApps faster and hence improve user experience. The variety of chains will offer a larger feature set too, which allows for feature-rich DApps. As Polkadot is being built with a light client in mind it should be possible to run a node on a low-power device (unlike most blockchains now).||The goal is for end users not to know that Truebit exists. The main impact will be latency, you have to wait for the Truebit process to complete.|
|11||Dependencies||Token standards, wallets (e.g. browser based wallets such as Metamask, mobile, desktop, etc.)||Multisignature contracts, need wallet integration.||None||web3 ecosystem: metamask, but used HTTP requests for messaging.||Requires wallet (MetaMask, local geth, local parity client).||The mainnet, POA network needs to be running, the bridge authorities need to have the bridge nodes running.||Rust and Solidity. Depend on the nodes which hold Parity Bridge. Full node for mainnet, POA network, currently we depend on powerful systems that have enough storage to store mainnet, this is another vector for development, to develop RPC to use these requirements to have huge storage.|
Right now to have a working bridge, it only works via IPC connections, need to have the same connections on the same machine, need to have an RPC connection.
|Right now Plasma chains are DApp-specific. Signing stuff is important and people are used to using Metamask, but the Plasma team think it would be wonderful to have different tools to use.||The developers draw from ethresear.ch sharding category posts. EWasm (phase 2); libp2p for the network protocol; Rust and associated software for core development; and Vyper for the Sharding Manager Contract.||Inter-Blockchain Communication (IBC) connections, peg zones / sidechains, Cosmos SDK||Download core client, or a light client if just interested in basic functionality||IPFS, or rather an incentivized version of it. EWASM.|
|12||Supporting Services||Metamask for signing.||Dont expect users to be available all the time (Randomly log on / off). This requires a third party to run a service to listen for me: “if I dont respond within 10 blocks then respond for me and I will pay you later.”.|
A general timestamping service would be beneficial.
|Dispute services. Availability services.||There’s a script to download all of the requests and verify what’s going on: shows team weren’t deleting messages.||Wallet to sign and verify signatures for transactions.||Everything like Metamask, Mycrypto and Parity where you can select just networks, you should be able to run both contracts through them. If you're using a small, exotic chain, Metamask, Mycrypto don't support it, you'll have to supply your own tooling. In a user flow, the user will have to change Metamask between networks. The DApp would need to say something.||Metamask, Block explorer, MyEtherWallet, MyCrypto, |
DApp automation for using two networks
|There is a need for a "watcher" to check what's running and making sure everything is happening as it's supposed to. It doesn't yet exist. Standardisation of block explorers would help.||Existing Ethereum infrastructure and tooling, e.g. Metamask, MEW, Infura, etc.||Want to see interchange identity and interchange usability services.||Parity Substrate, Parity wallet.||State channels depend on network of nodes.|
|13||Pain Points||Specialised solution, only payments, integration in wallets would be nice.||Devs need to design with channels in mind. If there are than two parties do processing then costs go up. Team unsure how that scales.||Shipping and the speed of the Ethereum nodes for off-chain transactions.||Final deployment of the non-fungible tokens.||User needs to be online to receive payment.||If you have authorities on a contract on one chain, want the bridge to work with that, it’s not impossible but it’s another project which is an ongoing problem but solvable. Open spam attack issue.||Update: block explorer is no longer a pain pointer after the release of BlockScout.||Accounts are single threaded which is a massive pain point because you have to wait for a transaction to resolve before being able to access an account again. If collecting fees for a bunch of different people, access to accounts needs to be very quick. This is an issue: for a transaction to be seen as received, it has to be seen by the child chain block which then needs to be included in main chain, the sender needs to confirm that it’s been included with no invalid transaction before it before funds can be counted as received and be ready for use again.||Complexity of communication across shards. More funding and more developers.||Need developers.||Not yet launched so there will be a learning curve.||Data availability - if someone passes a task but they never publish that code on IPFS. No one can really run this task, or they pose as a solver. / There needs to be an exchange to other tokens so that applications can use their native currency. Right now Truebit just uses ETH. / Breaking down the dispute code into small enough pieces to run on mainnet could be an issue.|