The State of Ethereum Scaling, March 2018
Highlights from EthCC on Plasma Cash, Minimum Viable Plasma, and More…
From the 8th to the 10th of March 2018, Paris got flooded with Ethereum professionals, researchers, investors and enthusiasts from all over the world for the Ethereum Community Conference (EthCC).
EthCC is organized by Asseth which is a French non-profit organization that has been promoting and sharing knowledge on Ethereum and its ecosystem since early 2016.
In total, more than 800 people attended (hint: me too!).
Over 100 talks were given over the 3 days of the conference, on topics ranging from Governance, Security, and Privacy to DApp development, Gaming, and Decentralized Exchanges. You can find most of the talks in the following spreadsheet.
Describing each talk is out of scope of this article. So since our focus at Loom Network is on scalability, in this article we’ll focus on covering the scalability talks of EthCC.
Plasma, Plasma Cash, and Sharding
On Day 2, Karl Floersch presented the latest progress on Plasma and Sharding. The talk is a slightly more detailed version of the Plasma explanatory video he uploaded last week.
This was probably my favorite talk, primarily due to Karl’s energy and enthusiasm about the concepts he described. At the moment, Plasma is designed for simple token transfers (ERC20/Ether), but it is extensible for more complex tokens such as ERC721 or even more general state transitions.
It should be understood that Plasma is not a protocol, it is a design pattern, a technique. The main requirement is that a Plasma Chain must be as secure as the root chain.
The main security mechanism behind the Plasma technique is “Plasma exits”, which is the process that allows a user who participates in a Plasma Chain to stop participating in the chain, and move their funds back to the Root Chain. Every Plasma Chain is also governed by its own “Plasma Operator”.
When a user is transacting in a Plasma Chain and wants to transfer their funds to the mainchain, they submit an “exit transaction” (i.e. a merkle proof of their transaction history proving they own a certain amount of money). At that moment, there is a “challenge period”.
The challenge mechanism has been seen in most off-chain solutions. Essentially, you allow anyone to challenge your claim by submitting a proof which marks your claim as invalid (in Plasma this can be a Merkle proof of the transaction history, in Payment Channels this can be a signed message from the other party).
In addition, when making a transaction that can be challenged, you are also required to attach a small bounty to it, in order to incentivize people to challenge you, if they believe your behavior was malicious. It’s like trying to steal something and saying “I’ll pay you $5 if you can catch me”.
In the normal case, if Bob wanted to transfer 5 PETH (Plasma Ether) back to the Root Chain, he’d submit an exit transaction (plus the bounty as collateral), and if it went unchallenged he’d be able to claim 5 ETH on the Root Chain. If Bob’s exit transaction was successfully challenged, it would get cancelled and the challenger gets the bounty
The more dangerous case is when the Plasma Operator wants to exit their chain. The described attack vector involves the Plasma Operator mining a block which gives them an arbitrary amount of PETH and then attempts to exit, and getting all the ETH locked in the smart contract for themselves. In this scenario, Sam’s and Alice’s PETH were minted earlier than the Plasma Operator’s PETH.
In an attempt to drain the Plasma Contract, if the Plasma Operator submits an exit, Sam and Alice notice that and they submit an exit as well. Older transactions are processed first, which means that they can safely get their PETH redeemed for ETH first, and when the Plasma Operator’s exit gets processed it is invalid, as the contract is now empty.
The second part of Karl’s presentation was on Plasma Cash, which is described below from Vitalik’s presentation.
The final part, was on Sharding, Phase 0 and Phase 1.
Sharding Phase 0:
- No hard fork
- Validator Manager Contract with a set of shard validators, up to 100 Ethereum shards, and data availability guarantees
Sharding Phase 1:
As described, there are 3 kinds of entities in Sharding:
- Users: Entities who send transactions
- Block Proposers: Entities who compute state transitions and propose blocks
- Validators: Validate blocks and ensure data availability
For a more detailed description on how block proposal works, watch Karl’s talk, you will love it.
The state of the Minimal Viable Plasma
David Knott presents the UTXO model of Plasma. A UTXO model, similarly to Bitcoin, involves a user who has a sum of transaction which have unspent outputs, and the sum of unspent output transactions (UTXO) makes up their balance. This is inefficient when trying to make a proof, since a user can have thousands of UTXO’s and that would increase the size of the proofs. In this case, an effort to simulate accounts is done, by a user sending all the UTXOs to themselves, and compacting them to one.
When a user deposits (locks) Ether in the Plasma Contract, a UTXO is generated for that amount. The user can then make as many transactions as they want on the Plasma Chain enjoying the benefits of fast confirmations and low fees. When they want to exit, they submit their UTXOs to the Root Chain’s contract and get their locked ether back.
The goal is to be able to have Plasma Chains of Plasma Chains that will offer different features. The security will be maintained by a similar mechanism to courts. In the case of a dispute, the next level of authority is invoked, until the dispute is finally resolved in the worst case scenario by the Root Chain.
Plasma Cash
Finally, Vitalik Buterin made a “surprise” talk where he reveals Plasma Cash, “Plasma with much less per-user data checking”. At the same time, due to the room being totally packed, Karl did an impromptu talk outside which you can watch here. The talk is also a live version of the discussion that is ongoing at the ethresear.ch forums.
Essentially, Plasma Cash is a version of Plasma with the following modifications¹:
- Every single deposit corresponds to a unique coin ID; tokens are indivisible and cannot be merged.
- Instead of storing transactions in a binary Merkle tree in order of
txindex, we require them to be stored in either a sparse simple Merkle tree or a Patricia tree, with the index being the ID of the coin that is spent.
This gives some non-fungible properties to the coin which in turn allow for optimizations on the proofs of its history. With that construction, a user needs only to validate the history (Merkle path, following the UTXO model) of the coins that they are watching, which allows for more efficient proofs compared to having to validate the whole chain of transactions for all coins.
Update: We announced our Plasma Cash Initial Release in June, 2018. See the official announcement here.
State Channels
I will focus on conducting a comparison of the three main players in the state channel space: Funfair, SpankChain and Raiden Network.
Funfair & Fate Channels
Since this is a gambling use case, there needs to be a source of randomness. When a payment channel is opened between a player and the casino, the RNG is seeded both by the player and the casino, which ensures a more secure source of entropy. Fate Channels are currently closed-source, which Jez described as a means to retain competitive advantage.
FunFair can do “turing complete state channels”, which are similar to SpankChain’s state channels and can do arbitrary state transitions (in contrast to Raiden which is made only for payments).
They require 1 transaction to open the channel, and 1 to settle. Any number of in-between transactions happens off-chain. Fate Channels are also short-lived, which means they last just for the duration of the game session.
SpankChain & Generalized State Channels
Ameen gave an overview of SpankChain’s ecosystem and then Nathan Ginnever did a deep dive in SpankChain’s State Channels implementation. Generalized State Channels and “Counterfactual instantiation” are terms which were coined by L4 and Counterfactual.
The idea is that both parties taking part in the state channel sign and share the bytecode for a smart contract, that can be deployed at any given time to the blockchain. The ability to pull the trigger at any time disincentivizes any dishonest behavior and is enough to make both parties adhere to the rules of the contract, without ever having it deployed.
This allows for zero onchain transactions in the case where both clients are acting as expected.
If a challenge arises, things are different:
A Bond Manager contract is responsible for opening and closing channels. It holds bonded ether/tokens and the balances decided in final states of closed sub-channels as interpreted by the off-chain client.
Raiden Network & Payment Channels
The talk on Raiden Network from Lefteris Karapetsas was an update to the progress and their roadmap. You can think of Raiden as Ethereum’s Lightning Network.
Raiden requires a computer that is able to run an Ethereum node and be live at all times. This is a hard task firstly because low-powered IoT devices cannot run an Ethereum node. In addition, being online anywhere at all times is still not the case due to network coverage and energy limitations.
Issues with usability still exist, such as mobile clients not being able to run a Raiden node. There is also extra overhead for adding proper security when targeting low-power devices. The currently available communication protocols such as whisper are neither scalable nor have low-enough latency for Raiden which lead them to use Matrix.
They refactored the code into multiple repositories which can be found at Raiden’s Github. Using the lessons learned from μRaiden, the new smart contracts are written with more respect to readability, security and gas optimization.
Each module of the Minimal Viable Product is approaching completion, and after testing on testnet and having an external audit, Raiden will finally launch to mainnet. If you are a developer, there is extensive documentation and you can contribute to Raiden by forking any of their repositories and submitting a Pull Request.
The following graph should give you a good side to side comparison of each State Channel solution:
Verified Offchain Computations
I feel this is not discussed enough. Oraclize provides a secure authenticated channel between any external datasource (e.g.: web APIs) and blockchain applications (like smart contracts, in the context of Ethereum)¹. This can be further extended to offload computational resources off-chain but still be able to verify their validity on chain for a cost of 60,000 gas.
This was further described in Oraclize’s Devcon3 talk. You can execute any Solidity function offchain, get its result via Oraclize and verify its authenticity. If the proof passes, you just saved a lot of gas, otherwise you can just execute the transaction on-chain (which reminds me of Truebit).
There was also a mention on how Oraclize can be used to enhance payment channels, although not described in depth.
Correct By Construction Casper, from Binary Consensus to Sharding
Vlad’s talk and research is focused on creating protocols that are well defined and can be ‘correct-by-construction’ (CBC). The concept is a little counter-intuitive. The traditional approach is to first create the protocol and then analyze it. CBC does the analysis first and then creates the protocol.
The Correct by Construction way:
- Formally but only partially specify the protocol
- Define properties and proofs that the protocol must satisfy
- Derive more of the protocol in a way that is proven to satisfy them
The goal is to make proving the protocol’s correctness almost trivial.
In this case, a set of mathematical rules is defined (some automata theory might help you out in this part) and then the protocol is designed with respect to these rules.
Vlad’s talk started with defining the rules and the terminology such as consensus safety:
If two states σ1 and σ2 have a common future protocol state σ3, by using the Forward Safety between σ1 and σ2 and the Backwards Consistency between σ3 and σ2, then all the decisions made at σ1 will be consistent with the decisions made at σ2. This results in σ1 having consensus safety with σ2.
For a more in depth explanation of consensus safety, refer to Theorem 1 of the paper.
Finally, in the Sharding part of the talk, merged blocks were described, which can be thought of as the ‘checkpoints’ for the shared history between shards.
I highly encourage you to view the talk here (slides), read the CBC paper, and view Vlad’s other talk on CBC protocols at the Ethereum Berlin meetup. This is still at research phase and there is no expected release date for mainnet.
I find Vlad’s talks to be very informative, although hard to follow, and often require full focus along with rewatching them so you should take your time on understanding this. This was the longest talk in the conference. CBC Casper and protocol design is a field which I find to be quite complicated and will try to cover it in a standalone article in the future.
What about Loom Network?
On our part of scalability, we are building a software SDK for users to be able to build their own DAppChains, a specialized form of sidechain for non-financial use cases. Learn more about Loom’s DAppChains in our recent posts:
- Million-User DApps on Ethereum: An introduction to Application-Specific Sidechains
- DAppChains: Scaling Ethereum DApps Through Sidechains
This was a long post! You should now have a good idea of the state of each scalability project and how things are moving forward. All projects are open-source so go ahead and contribute.
Next steps:
- Got questions? Ask on DelegateCall.com, our blockchain-based Q&A site, and earn ERC20 tokens for your contributions!
- Get updates from us directly to your inbox by joining the Loom Network mailing list
- Want to chat about scaling Ethereum? Hop into our Telegram and join the conversation.
Loom Network is the multichain interop platform for scaling high-performance dapps — already live in production, audited, and battle-tested.
Deploy your dapp to Loom’s Basechain once and reach the widest possible user base across all major blockchains today.
New to Loom? Start here.
Want to stake your LOOM tokens and help secure Basechain? Find out how.
Like what we’re doing here? Stay in the loop by signing up for our private mailing list.
