This spreadsheet shows a summary of scaling solutions presented on the first day of the ScalingNOW! workshop in Barcelona.
|Parity Tech||POA Network||Cosmos||Plasma||TrueBit|
|Link to project||https://raiden.network/micro.html||https://counterfactual.com/||https://funfair.io/||https://decentraland.org/||https://github.com/paritytech/parity-bridge||https://poa.network/||http://cosmos.network/||https://plasma.io/||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 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.||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.
|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.||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.||6 months||There is a live minimum viable product. Full solution is less than 4 months away.||Happened (December 2017, custom solution). New use-cases and solutions possible but no date indicated for completion.||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.||Tendermint core is ready now. Cosmos SDK is in alpha. IBC is ~70% ready, 3-4 months out. Ethermint Sovereign will be ready in 4 months, hosted 1 month after.||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 this year.||Bottom: Computation layer. 6 months.|
Middle: Verification game. 6 months.
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.||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.||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)
|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.
|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.||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.||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.
|Can build an app-specific sidechain or an app-specific function into the sidechain.||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.||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.||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.||An underestimate: 1 OOM, but team suggest it could be much higher.||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).||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.||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.
|There can be a withdrawal latency which can be exascerabated if everyone tries to exit at the same time.||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.||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.||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.
|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).||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.||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.
|Proof of Stake is not thought to be as expensive as Proof of Work, so fees ought to be lower.||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).||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.||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.
|On-chain governance to allow for upgradeability. Two upgradability modes:|
- Upgrade the underlying blockchain
- Ethermint - deploy new model of the smart contract
|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.||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.||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.||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.||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.||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.||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.
|Inter-Blockchain Communication (IBC) connections, peg zones / sidechains, Cosmos SDK||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.||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.||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
|Want to see interchange identity and interchange usability services.||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.||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.||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.||Block explorer.||Need developers.||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.||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.|