Ethereum Layer 2 Scaling Solutions: State Channels, Plasma, and Truebit
Editor's Note: This article comes fromEditor's Note: This article comes from, translator JohnJiangLA, proofreader foxxnuaa Zheaoli; original text from medium, authorJosh Stark; Odaily reproduced with authorization.
; Odaily reproduced with authorization.
Pennsylvania Tunkhannock Regional Rail Viaduct (cc). Ancient Roman architectural ideas in use in the new age.
For Ethereum, 2018 is a year of focusing on infrastructure. This is the year for early adopters to test the limits of the network and to refocus on some of the technologies that scale Ethereum.
Ethereum is still in its infancy. Today, it is not secure or scalable. Technicians are well aware of this. But in the last year, the hype generated by numerous ICOs has begun to exaggerate the current network capabilities. Building a secure, easy-to-use decentralized internet, governed by a common set of economic norms and used by countless people, the beautiful promise of ethereum and web3 is here, but only if critical infrastructure is in place Only then can it be realized.
Projects working on building this infrastructure and scaling Ethereum's capabilities are often referred to as scaling solutions. These programs take different forms and are often compatible or complementary to each other.
In this long post, I want to dive deeper into one scaling solution: the "off-chain" or "layer 2" solution.
First, we will discuss the scaling challenges of Ethereum (and all public blockchains) in a comprehensive manner.
Second, we describe different approaches to solving scaling challenges, distinguishing between "layer 1" and "layer 2" solutions.
Finally, we'll dive into layer 2 solutions and explain how it works in detail, we'll talk about state channels, Plasma, and Truebit.
The focus of this article is to give readers a comprehensive and detailed explanation of the concept and working principle of the second layer (layer 2) solution. But we won't delve into the code or specific implementation. Instead, we focus on understanding the economic mechanisms used to build these systems and the common mindset across all second-layer technologies.
1. Scaling problems of public blockchains
First of all, you need to know that "scaling" is not a single, specific problem, it involves a series of difficult problems that must be solved to make Ethereum usable to countless users around the world.
The most commonly discussed scaling challenge is transaction throughput. Currently, Ethereum can process about 15 transactions per second, while Visa's processing capacity is about 45,000/tps. In the last year, some applications (such as Cryptokitties or the occasional ICO) have become popular enough to "slow down" the network speed and increase the price of mining fees (gas).
The core flaw of public blockchains (such as Ethereum) is that every transaction is required to be processed by every node in the network. A payment, the birth of Cryptokitty, the deployment of a new ERC20 contract, and every operation that occurs on the Ethereum blockchain must be executed in parallel by every node in the network. This is determined by the design concept, and it is precisely because of this design concept that the public blockchain is authoritative. Nodes don't need to rely on other nodes to tell them the current state of the blockchain, they figure it out themselves.
This places a fundamental limit on Ethereum's transaction throughput: it cannot exceed our design requirements for a single node. .
We can ask each node to do more work, and if we double the block size (e.g. block gas limit), this means that each node has roughly twice as much work to process per block. But this weakens the idea of decentralization of the system: more work for nodes means that less powerful computers (such as user devices) may be withdrawn from the network, and mining will be favored by more powerful node operators concentrated.
Instead, we need a way to make the blockchain do more useful things, but not increase the workload of individual nodes.
Conceptually, there are two possible solutions to this problem:
1. What if every node didn't have to process every operation in parallel?
The first approach throws away our premise, what if we could build a blockchain where every node didn't have to handle every operation? What if the network was divided into two parts to replace the original network, each part could operate independently?
Part A can process one batch of transactions while part B can process another batch. This effectively doubles the transaction throughput of the blockchain. Because of our limit it can now be processed by two nodes simultaneously. If we can divide the blockchain into many different parts, then we can increase the throughput of the blockchain many times over.
This is the mindset of sharding, a scaling solution that Vitalik's Ethereum Research group and others are working on. A blockchain is divided into different parts called shards, each of which can process transactions independently. Because sharding is implemented in the base level protocol of Ethereum, it is often called the first layer (layer 1) expansion solution. If you want to know more about sharding, please check the extensive FAQ and this blog posts.
2. If we can squeeze more useful business operations out of Ethereum's existing capabilities
The second option goes in the opposite direction: instead of increasing the capacity of the Ethereum blockchain itself, what if we could do more with the capacity we already have? The productivity of the Ethereum blockchain at the basic level is the same, but in reality, we can do more operations that are useful to humans and applications, such as transactions, state updates in games, or simple calculations.
This is the thinking behind "off-chain" technologies such as state channels, Plasma, and Truebit. While each of these solutions is solving a different problem, they all operate "off-chain" and are able to operate off the Ethereum blockchain while still maintaining sufficient security and authority.
These are also known as layer 2 solutions because they are built “on top” of the Ethereum main chain. They don’t require changes to the protocol at a fundamental level, instead they simply serve as smart contracts on Ethereum for interacting with off-chain software.
2. Layer 2 solutions are cryptoeconomic solutions
Before diving into the specifics of a second-layer solution, it's important to understand the underlying details that make it feasible.
The power source of the public blockchain lies in the encrypted economic contract. By aligning incentives and securing them with software and encryption, we can create a stable network of computers that agree on their internal state. This is a key element of Satoshi Nakamoto's white paper, which has been used in the design of many different public blockchains, including Bitcoin and Ethereum.
Except for some extreme cases (such as 51% attacks), encrypted economic contracts give us a solid core. We know that on-chain operations (such as payments, smart contracts) can be seen as written to execute.
The key behind layer 2 solutions is that we can use this solid core as an anchor, a fixed point to which other economic mechanisms can be attached. This second-layer economic mechanism can extend the usability of public blockchains. Let's interoperate off the blockchain and still reliably get back on the core chain if needed.
These layers built “on top” of Ethereum don’t always have the same guarantees as on-chain operations. However, they are still authoritative, secure and usable enough, especially with a slight reduction in endpoints, that we can perform operations faster or maintain lower overhead costs.
The encryption economy does not start or end with Satoshi Nakamoto's white paper, it is the most suitable technical subject for us to learn and apply. Not only in the design of the core protocol, but also in the design of second-layer systems that extend the functionality of the underlying blockchain.
1. State channels
A State Channel is an "off-chain" technology for executing transactions and other state updates. However, transactions that occur "in" a state channel still maintain a high level of security and authority. If anything goes wrong, we still have the option of reverting to the "solid core", whose authority is based on on-chain transactions.
Most readers will be familiar with a concept that has existed for many years - the payment channel (payment channel), which was recently implemented on Bitcoin with the help of the lightning network (lightning network). The state channel is a generalized form of the payment channel. It can be used not only for payment, but also for arbitrary "state updates" on the blockchain, such as changes in smart contracts. In 2015, Jeff Coleman described state channels in detail for the first time.
The best way to explain how state channels work is to look at an example. Please keep in mind that this is a conceptual explanation, which means we won't get into the technical details of the implementation.
Now imagine that Alice and Bob want to play a game of tic-tac-toe, and the winner gets one ether. The easiest way to do this is to create a smart contract on Ethereum that implements the rules of Tic Tac Toe and keeps track of each player's actions. Every time a player wants to move, they send a transaction to the contract. When a player wins, according to the rules, the contract pays the winner one ether.
This works, but is inefficient and slow. Alice and Bob are using the entire ethernet network for their game play, which is a bit of an outlier for their needs. They need to pay the mining fee (gas) every step, and they also have to wait for the mining to complete before proceeding to the next step of the game.
However, we can design a new system that enables Alice and Bob to play tic-tac-toe with as few on-chain operations as possible. Alice and Bob are able to update the game state off-chain while still bringing it back on the Ethereum mainchain when needed. We call such a system a "state channel".
First, we create a smart contract "Judge" on the Ethereum main chain that can understand the rules of Tic Tac Toe, and it can also identify Alice and Bob as the two players in our game. The contract holds a reward of one ether.
Then, Alice and Bob start playing the game. Alice creates and signs a transaction that describes the first step of her game, sends it to Bob, who signs it, sends the signed version back and keeps a copy. Then Bob also creates and signs a transaction describing his first move in the game, sends it to Alice, and she signs it, sends it back, and keeps a copy, and they update each other's games every time current status. Each transaction contains a "random number", so that we can directly know the order of moves in the game.
So far, no on-chain operations have occurred. Alice and Bob are just sending transactions to each other over the internet, but nothing touches the blockchain. However, all transactions can be sent to the Judge contract, that is, they are valid Ethereum transactions. You can think of this as two people writing a series of blockchain-authenticated checks back and forth between each other. No money was actually deposited or withdrawn from the bank, but they both had a stack of checks ready to be deposited.
When Alice and Bob end the game (probably because Alice won), they can close the channel by submitting the final state (e.g., transaction list) to the Judge contract, thus only paying the transaction fee once. The Judge will make sure that both parties have signed this "final state", wait for a period of time to ensure that no one can reasonably challenge the result, and then pay Alice a reward of one ether."Why do we need to set a Judge contract to wait"
question time
Suppose, instead of sending Judge a copy of the real final state, Bob sends a copy of the state where he won Alice before. At this time, if Judge is a non-smart contract, it has no way of knowing whether this state is the latest state.
The challenge time gives Alice a chance to prove that Bob submitted a false end state of the game. If there is a more recent state, she has a copy of the signed transaction and can provide it to Judge. The Judge can tell if Alice's version is newer by checking the nonce, and Bob's attempt to steal the win can be dismissed.
Features and Limitations
State channels are useful in many applications, and they are a neat improvement over performing operations on-chain. But when deciding whether an application is suitable for being channelized, be aware of some specific trade-offs that need to be made:
State channels depend on reliability. If Alice goes offline during the challenge time (perhaps Bob, desperate to win the prize, destroys her internet connection at home), she may not be able to respond during the challenge time. However, Alice can pay someone else to keep a copy of her state and represent her interests in order to maintain the reliability of the system.
State channels are useful in situations where large numbers of state updates need to be exchanged over a long period of time. This is due to the initial cost of creating a channel when deploying the Judge contract. But once the deployment is complete, the cost of each state update in the channel will be very low.
State channels are best suited for applications with a well-defined set of participants. This is because the Judge contract must always be aware of all entities (eg, addresses) participating in a given channel. We can add or remove users, but each time we need to change the contract.
State channels have strong privacy properties. Because everything happens "within" channels between participants, rather than public broadcast and recorded on-chain. Only opening and closing transactions must be made public.
The authority of the state channel is immediate. This means that as soon as both parties have signed a state update, it can be considered final. Both parties have explicit guarantees that they can "execute" the state on-chain if necessary.
Counterfactual is a framework that implements state channels on Ethereum. The goal is to enable developers to modularly use state channels in their projects without needing to be state channel experts. Publish the technical details document in the first quarter of 2018.
Besides Counterfactual and Raiden, there are several application-specific channel implementations on Ethereum. For example, Funfair built a set of state channels they call "Fate channels" for their decentralized gambling platform, SpainChain built a set of one-way payment channels for adult project actors (they are still in their ICO using state channels), and Horizon Games also used state channels in their first Ethereum-based game.
text
2. Plasma
On August 11, 2017, Vitalik Buterin and Joseph Poon published a document titled Plasma: Autonomous Smart Contracts. This document introduces a new technology that enables Ethereum to process far more transactions per second than it currently does.
Like state channels, Plasma is a technology for managing off-chain transactions while relying on the underlying Ethereum blockchain for its security. But Plasma takes a new approach by creating "child" blockchains attached to the "main" Ethereum blockchain. These sub-chains can in turn generate their own sub-chains in turn, which can be repeated in turn.
plasma.io/plasma.pdf
The result is that we can perform many complex operations at the subchain level, running full-fledged applications with thousands of users while maintaining minimal interaction with the Ethereum main chain. Plasma child chains can migrate faster and incur lower transaction fees because operations on them do not need to be repeated on the entire Ethereum blockchain.
To understand how Plasma works, let's look at an example of how it can be used.
Imagine you are creating an Ethereum-based card trading game. These cards are some ERC 721 non-fungible tokens (such as Cryptokitties), but have some characteristics and attributes that allow players to play against each other, which is a bit like Hearthstone or Magic: The Gathering. These types of complex operations are very expensive to perform on-chain, so you decide to use Plasma in your application as an alternative.
First, we create a series of smart contracts on the Ethereum main chain, which can be used as the "root node" of the Plasma sub-chain. The Plasma root node contains some basic "status transaction rules" of the sub-chain (such as "transactions cannot consume assets that have been consumed"), and also records the hash value of the sub-chain state, and establishes a method that allows users to trade in the Ethereum main chain. A "bridge" service for transferring assets between subchains.
Then, create our child chain. A child chain can have its own consensus algorithm, in this example we assume it uses Proof of Authority (PoA), a simple consensus mechanism that relies on trusted block producers (e.g. validators). In a "proof-of-work" system, block producers and miners function similarly, they are nodes that receive transactions, form blocks and collect transaction fees. To keep the example simple, let's assume that you (i.e. the company creating the game) are the only entity creating blocks, i.e. your company operates several nodes, which are the block producers for the child chains.
Once the sub-chain is created and takes effect, the block producer will periodically send submissions to the root node contract. That is, they are effectively saying "my submission X is the current latest block in the child chain". These commits are recorded in the Plasma root node of the chain as proof of transactions in the child chain.
Now that the child chains are also ready, we can create the basic components of the card trading game. These cards follow ERC721, initialized on the Ethereum main chain, and then transferred to the child chain by the Plasma root node. A key point is introduced here: Plasma can expand our interaction with blockchain-based digital assets, but these assets should be created by the Ethereum main chain in the first place. Then, we deploy the actual game application to the sub-chain in the form of smart contracts, so that the sub-chain contains all the logic and rules of the game.
When users want to play games, they only need to interact with the child chain. They can hold properties (ERC721 cards), buy and exchange them for ETH, play against other users, and other in-game actions, all without interacting with the main chain. Since only a small number of nodes (e.g., block producers) need to process transactions, fees are much lower and operations are faster.
But is this pattern safe?
By migrating operations from the main chain to sub-chains, we can obviously perform more operations. But is it safe? Is the transaction on the child chain authoritative? After all, the system we just described has only one central entity controlling the block production of child chains. Isn't this centralized? Wouldn't the company be able to steal your assets or take your collectible cards at any time?
In simple terms, Plasma makes the basic promise that you can withdraw your assets back to the main chain at any time, even in scenarios where a single entity in the child chain has full control over block production. If a block producer starts to show hostility, at worst it will just force you to leave the child chain.
Let's look at a few ways block producers behave badly, and how Plasma handles these scenarios.
First, suppose a block producer is trying to deceive you by lying, they can create a fake new block, claiming that your assets have been taken over by them. Since they are the only block producers, they are free to introduce a new block that does not follow the rules of the blockchain. Like other blocks, they also have to push proof of the existence of this block as a commit to the Plasma root node contract.
Plasma also creates a mechanism to prevent exploit fraud. Plasma includes a mechanism by which anyone (including you) can issue a fraud proof to the root node contract, thus proving that the block producer cheated. This fraud proof will contain the information of the previous block and allow us to follow the state transaction rules in the sub-chain, and the wrong block cannot be connected to the previous state correctly. If the fraud is confirmed, the subchain rolls back to the previous block. Even better, we also built a system where block producers who check out the wrong block are penalized, and these block producers lose an on-chain deposit.
image description
In this case, this scheme is prepared for Alice to recover the assets and leave the child chain. Essentially, Alice submits a "fraud proof" to the root node contract. After a delay period in which anyone can challenge the proof (for example, to show that some later legitimate block proves that she actually spent the assets), Alice's assets will be moved back to the Ethereum main chain.
image description
Finally, block producers can monitor users in child chains. If block producers wish, they can simply not include actual transactions in their blocks, effectively preventing users from performing any actions on the child chain. As mentioned above, this solution once again directly returns all our assets to the Ethereum main chain.
However, withdrawing assets also carries risks of its own. One of the concerns is what happens if all users using this subchain have to withdraw assets at the same time. In the case of such a large withdrawal, there may not be enough capacity on the Ethereum main chain to process everyone's transactions during the challenge period, which means that users may lose funds. Although there are many possible techniques to prevent this from happening, for example, by extending the challenge time to accommodate the need to withdraw assets.
It is worth noting that it is not a given that all block producers are controlled by one entity, it is just an extreme case in our case. We can create sub-chains where block producers are distributed among different entities, i.e. truly decentralized like public blocks. In these cases, there is less risk of blockchain producers interacting in the manner described above, and less risk of users having to transfer assets back to the Ethereum main chain.
Now that we have introduced state channels and Plasma, a few points are worth comparing.
One difference between them is that when all interested parties in the state channel agree to withdraw, it can be withdrawn immediately. If Alice and Bob agree to close the channel and withdraw their funds. As long as they all agree on the final state, they can get their assets immediately. This is not possible on Plasma, as mentioned above, users must include a challenge time in the process of withdrawing assets.
State channels are cheaper per transaction and faster than Plasma. This means we can establish state channels on Plasma child chains. For example, an application where two users are conducting a series of small transactions. Setting up a state channel on a child chain should be cheaper and faster than executing each transaction directly on the child chain.
III. Truebit
Finally, it should be noted that this part of the explanation is missing a lot of detail. Plasma itself is in its very infancy. If you're interested in seeing what's happening with plasma today, check out Vitalik's recent proposal for a "Minimal Viable plasma" (i.e. abstracting away the plasma implementation). A Taiwanese team is working on this and can be viewed in this fork. OmiseGo is working on their distributed transaction implementation, and they posted a recent update on their progress here.
Truebit is a technology that helps Ethereum perform heavy or complex calculations off-chain. It is more effective for increasing the total transaction throughput of the Ethereum blockchain, which makes it different from state channels and Plasma. As we discussed in the opening section, scaling is a multifaceted puzzle that requires more than just higher transaction throughput. Truebit won't let us do more transactions, but it will allow Ethereum-based applications to handle more complex transactions and still be verified by the main chain.
This allows us to do useful operations on Ethereum applications that would be too computationally expensive to perform on-chain. For example, verifying Simple Payment Verification (SPV) proofs from other blockchains, by which Ethereum smart contracts can "check" whether a transaction occurred on another chain (such as Bitcoin or Dogecoin).
Let's look at an example. Imagine you have some expensive computation (like SPV proofs) that needs to be performed as part of an Ethereum application. Because the computational cost of SPV proofs is too high, you cannot simply include them as part of a smart contract on the Ethereum main chain. Keep in mind that performing any computation on Ethereum is very expensive because each node has to perform the operation in parallel. Blocks in Ethereum have a maximum fee (gas) limit, which is used to limit the total amount of calculations that can be done by combining all transactions in the block. However, an SPV proof is so computationally intensive that it would still require many times the full fee limit of a single block even if it were the only transaction in it.
On the contrary, you only need to pay a small fee to complete the calculation off the chain. The person you pay to do the calculation is called a solver.
First, the solver pays a deposit to the smart contract. Then, you give the solvers a detailed description of the computation, they run the computation, and they return the result. If the result is correct (which mostly happens within a second), their deposit will be returned. If the solvers are proven to have performed incorrectly (for example, they cheated or made a mistake), they lose their deposit.
Since the verification game is executed on-chain, it cannot simply compute the result (which would defeat the purpose of the whole system, and if the computation could be performed on-chain, we wouldn't need Truebit). Instead, we ask the solver and challenger to identify specific operations on which they disagree. In effect, we sided with both sides to a corner and figured out the specific line of code that caused their disagreement about the results.
image description
A simplified conceptual diagram of Truebit
If you want to learn more about Truebit, you can check out this document, or this blog post by Simon de la Rouviere.
in conclusion
in conclusion
Layer 2 solutions share a common vision. Once we get the stable core provided by the public blockchain, we can use it as the anchor point of the encrypted economy to expand unlimited blockchain applications.
Now that we've surveyed some samples, it's possible to see more concretely how second-tier solutions can achieve this vision. The economic mechanisms employed in second-layer solutions are often interactive games: they work by creating incentives for parties to compete or “check” each other. Since we create a strong incentive for the other party to produce corroborating false information, a blockchain application can assume that a given statement is true.
In the state channel scheme, the final state of the channel is determined by giving each party an opportunity to "refute" the other party. In the Plasma scheme, this is how fraud proofs and withdrawals are managed. In the Truebit scheme, the challenger is encouraged to prove that the solver is wrong, so as to ensure that the solver gives the correct result.
These systems will help solve a number of challenges involved in scaling Ethereum to a global user base. Some systems, like state channels and Plasma, will increase the transaction throughput of the platform. Other systems, like Truebit, will be able to perform more complex calculations as part of smart contracts, creating new use cases.
These three examples represent only a fraction of the possible designs for cryptoeconomic scaling scenarios. We haven't even talked about "inter-blockchain agreements" like Cosmos or Polkadot (although that's for "second layer" solutions or another blog post). We should still expect to invent unexpected new layer-two systems that improve upon existing models or make new trade-offs in speed, latency, and overhead.
More important than any unique second-layer solution is the further development of the underlying technologies and mechanisms that make these cryptoeconomic designs possible.
These second-layer scaling scenarios are a strong case for the long-term value of programmable blockchains like Ethereum. It is only possible to build an economic mechanism based on a second-layer solution on a programmatic blockchain: you need to implement a program in a scripting language to execute an interactive game. This is difficult (or in some cases, like Plasma, completely impossible) for blockchains such as Bitcoin that only offer limited scripting capabilities.
The emergence of Ethereum's second-layer solution allows us to make new trade-offs between speed, terminal and overhead. This is where the underlying blockchain can be adapted for a wider variety of applications. Therefore, different types of applications facing different threat models will naturally choose different trade-off models. For large-scale transactions that need to be secured on a regional (or even national) scale, we use the main chain. For more speed-oriented digital asset transactions, we can use Plasma. The second-layer solution allows us to make these trade-offs without compromising the underlying blockchain, and maintain decentralization and authority.
Also, it is difficult to predict in advance which scripting capabilities will be required for a given scaling scenario. When Ethereum was designed, Plasma and Truebit had not yet been invented. But because Ethereum is fully programmable, it can implement any economic mechanism we can invent.
The value of blockchain technology is built on the stable core of encrypted economic contracts, and programmable blockchains such as Ethereum are the only way to fully utilize this value.
