Ethereum Layer 2 Expansion Plan: Status Channel, Plasma, and Truebit

Ethereum is not yet sound and not scalable. Anyone who knows this technology knows this clearly. But in the past year, speculation-driven hype has overstated the blockchain's capabilities. The vision of Ethereum and web3 was not realized until the critical infrastructure was perfected.

Projects that build this infrastructure and extend Ethereum functionality are called expansion plans. Expansion plans come in many different forms and are often compatible or complementary.

This article will delve into the "chain" or "layer 2" expansion options, including:

1. Ethereum (and all blockchains) expansion challenges

• JPMorgan expands the Zether protocol or develops new privacy features for the Quorum project
• Opinion: Please pay attention to "application governance", which is the top of DApp's Achilles
• 2 hours of brainstorming, ant experts and more than 40 CEOs' exchange essences, here are the ants ant blockchain contest Chengdu Road Show, hot collection

2. Different solutions to the problem of capacity expansion, and distinguish between “Layer 1” and “Layer 2”.

3. Introduce what the Layer 2 expansion scheme is, especially state channels, Plasma, and Truebit.

The focus of this article is to give the reader a comprehensive and detailed understanding of how Layer 2 works. But instead of delving deeper into code research and specific usage scenarios, it focuses on the economics of building the system and the technical principles of the Tier 2 expansion scheme.

Expansion of the public chain

First of all, it must be known that “expansion” is not a single, specific issue. It is a problem that Ethereum must solve before serving billions of users around the world .

The first is transaction throughput. Currently, Ethereum can process 15 transactions per second, compared to Visa processing speeds of up to 45,000 strokes per second. In the past year, some applications, like Cryptokitties, have developed well, causing the entire network to slow down and the transaction price to increase.

A public chain like Ethereum requires every node in the network to participate in the processing of each transaction, and its main limitations are also here. Every operation on Ethereum – transfer, the birth of Cryptokitty, the generation of ERC20 contracts – must be performed by each node in the network. This is one of the reasons for the design and the reason why the public chain is authoritative. Nodes do not need to know the state of the blockchain from the outside, they can solve it themselves.

This sets a fundamental limitation on Ethereum's transaction throughput: it cannot be higher than the speed of data obtained from a single node.

We can ask each node to do more work. If we double the block size, this would mean that each node does about twice as much work as it does today. But this comes at the expense of decentralization: if nodes need to do more work, then weaker computers (such as consumer devices) may quit the network, and mining rights will be concentrated in the hands of powerful operators. .

We need a solution that not only increases the load on a single node, but also handles more transactions.

Conceptually, we can take two approaches to solve this problem:

1) What if each node does not have to process each operation in parallel?

The first method, subverting the premise: If we can build a blockchain, the nodes in the chain do not have to deal with each transaction? If the network is divided into two parts, can it operate semi-independently?

After being separated, Zone A can handle a batch of transactions, and Zone B can also process a portion. This doubles the blockchain transaction throughput because we now set every two nodes to work at the same time. If we divide the blockchain into many different areas, the throughput will increase many times.

This is the idea behind “sharding”, which was proposed by Ethereum V God and other researchers. A blockchain is divided into a number of different "slices", each of which can handle transactions independently. Fragmentation generally refers to the expansion scheme of Tier 1 because it is implemented on the Ethereum's grassroots protocol.

2) What if I set up a protocol layer network for Ethereum?

The second option is the opposite of the first: instead of increasing the capabilities of Ethereum itself, it is better to take measures on its basis. The throughput of the Ethereum blockchain base layer is constant, but in fact we can perform more operations, such as transactions, status updates or simple calculations.

This is the principle behind the "chain" technology, like the state channel, Plasma, Truebit. Although each technology is designed to solve different problems, they all need to be "chained down" under the premise of ensuring security.

This is also known as the Tier 2 expansion scheme because they are above the Ethereum main chain. They do not need to be changed at the base layer but exist as smart contracts that interact with the underlying software.

Layer2 is a digital economy solution

Before you talk about Layer 2 solutions, let's take a look at the principles behind them.

The basic strength of the public chain lies in the digital economic consensus. Consensus is reached from within the system by carefully aligning incentives and combining them with cryptography. This is also the focus of the Nakamoto white paper, which has now been applied to many different public chains, including Bitcoin and Ethereum.

The digital economy consensus gives us a hard core—unless extreme events like the 51% attack occur, all operations (including payments, or smart contracts) will be performed as written.

The rationale behind the Layer 2 solution is that we can use this deterministic kernel as an anchor—adding other economic mechanisms to it. Layer 2 can extend the utility of the public chain beyond the chain, allowing us to interact outside the chain, and these interactions can still be returned to the main chain when needed.

These layers are built on the Ethereum main chain, so it is not as safe as chain operations. But you can still make sure that they are ultimately, safely, and practically—especially with only a little bit of operational authority at a time, you can increase operational efficiency and reduce processing costs.

Digital economics is not started by Nakamoto's white paper, and it won't end there – it's the technology we're trying to apply. Not only in the design of the core protocol, but also in the design of a Layer 2 solution designed to extend the functionality of the underlying chain.

1, state channels (State channels)

A state channel refers to a technique of "under the chain" that handles transactions and other operations. However, things happening in the state channel are still highly secure and final: if something goes wrong, we can still choose to go back to the chain.

Many readers know the payment channel, which has been around for many years and is also implemented on Bitcoin through the lightning network. State channels are a more common form of payment channel – they can handle not only payments, but also "state updates" of blockchains – just like smart contract changes. In 2015, Jeff Coleman first proposed a state channel.

Looking at an example, you can better explain how the state channel works. Please note that this is a conceptual explanation and we will not discuss specific technical details.

Imagine Alice and Bob playing tic tac toe and the winner can get 1ETH as a reward. The easiest way is to create a smart contract on Ethereum, write the rules of the three-game game into the smart contract, and track the movement of each player's pieces. Each time the player moves the piece, it is sent to the contract once. When a player is born, according to the rules, the contract will pay 1 ETH to the winner.

Although this is feasible, it is inefficient and slow. Alice and Bob's entire Ethereum network are running for this game, causing waste of resources. Every time a player moves a move, they pay a fee, and they have to wait for the miner to complete the verification before proceeding to the next step.

At this time, we can design a system that allows Alice and Bob to interact as much as possible under the chain. Alice and Bob can update the status under the chain and return to the chain transaction when needed. We call this system a "state channel."

First, we created a smart contract as a “judge” on the Ethereum main chain, and wrote the rules of the game into the contract, identifying that Alice and Bob are the two players in the game. Give this contract a 1ETH bonus.

Then, Alice and Bob began to interact. Alice started the first step, signed it and sent it to Bob. Bob also signed it and sent back his signed version to save a copy of himself. Then Bob took a step, signed it and sent it to Alice. Alice also signed it and sent it back, saving the copy himself. Every time they update their status. Each interaction includes a "random number nonce", which allows each interaction to be timed.

At this point, all operations do not occur on the chain. Alice and Bob only trade on the Internet, but all transactions can be uploaded to the contract – in other words, they are still valid Ethereum transactions. You can understand that these two people are cheques that write blockchain certification back and forth. Banks do not have deposits or withdrawals, but each check can be deposited at any time.

If Alice and Bob's game ends, say Alice wins, they can upload the final status (transaction list) and close the channel. In this way, it is enough to pay only one transaction fee. The contract ensures that the "final state" has both parties signed and waits for a period of time to ensure reliable results, and finally pays 1 ETH's bonus to Alice.

Why do you need this waiting time?

Suppose Bob is not uploading the final version, but he won the version of Alice. But the contract only executes the instructions and cannot know which one is the final version. At this time, set a waiting time, which allows Alice to provide evidence that he is providing the final version.

Alice submits a copy of the transaction signed by both parties. The contract determines the final version submitted by Alice through the nonce of the transaction and rejects Bob's request.

Features and limitations

The status channel is suitable for many applications and has many upgrades to traditional chain operations. However, other factors must be considered before introducing the state channel:

1) The status channel depends on availability. If Alice breaks the network during the process (assuming that Bob is eager to get a bonus and destroys Alice's network), she may not be able to submit status information in a timely manner. Even so, Alice can pay for others to save her trading status and act as her representative to maintain data availability.

2) This status channel is particularly suitable if the user wants to make many status updates and lasts for a long time. This is because although a fee is required for creation, maintenance costs are particularly low.

3) The status channel is for those applications that are fixed by the user. Because the contract must know all the entities in the channel. Although it is possible to add or remove people, it all requires changes to the contract.

4) The status channel has strong privacy attributes. Because all operations occur in the "internal" channel, they are not posted on the chain and are not recorded in the chain. Only the beginning and end of the transaction are public.

5) The status channel has immediate final certainty. In other words, once both parties have signed the status, they can be considered final. If necessary, it can also be "forced" to execute on the chain.

L4 is building a Counterfactual: a stateful channel framework based on Ethereum, which plans to implement a common, modular template and allows developers to use stateful channels in their applications without having to become a state channel expert themselves.

Another state channel project worthy of attention is Raiden, whose goal is to create a payment channel that uses a model similar to Lightning Networks. This means that instead of opening a channel with a specific person, you can also open a channel with a larger network of channels so that you can trade with anyone else connected to the same channel without a fee.

In addition to Counterfactual, Raiden, there are several applications based on Ethereum. For example, Funfair created a one-way payment channel for adult actors for their decentralized platform ("Fate channels") (they also created a status channel for ICO), and Horizon games created for their Ethereum games. State channel.

2, Plasma

On August 11, 2017, Vitalik Buterin and Joseph Poon published a paper titled "Plasma: Autonomous Smart Contract." This article introduces a new technology that can improve the processing efficiency of Ethereum.

Like the state channel, Plasma is a technology for dealing with chain transactions and relies on the underlying technology of Ethereum to protect its security. But Plasma's entry point is different, it allows to create a "child" blockchain on the Ethereum main chain. These "sub-chains", in turn, can also create their own "sub-chains", and so on.

As a result, we can perform many complex operations at the sub-chain level, run applications with thousands of users, and only use very little interaction with the Ethereum backbone. Plasma can run very quickly and charge a lower transaction fee because the entire process does not need to happen on the Ethereum main chain.

But submitting evidence of fraud requires access to basic data, the actual history of the blocks used to prove fraud. What if the block producer does not share information about the previous block to prevent Alice from submitting evidence of fraud to the root contract?

In this case, Alice needs to withdraw her funds and leave the sub-chain. In fact, Alice submitted a “fund certificate” to the root contract. After waiting for a while, anyone can question her proof (for example, to prove that she spent the money in a later valid block), Alice's funds were moved back to the Ethereum main chain.

Let's look at an example to understand how Plasma works.

Let's imagine that you are creating a trading card game on Ethereum. These cards are ERC 72 tokens (such as Cryptokitties), but they have certain features and attributes that allow users to play games such as Hearthstone or Magic the Gathering. Performing these complex operations on the chain is expensive, so using Plasma is a good choice.

First, we created a smart contract in the Ethereum main chain as a "Root" serving our Plasma sub-chain. Plasma Root contains the "state transition rules" of our sub-chains (such as "can't double flower"), which records the hash of the state of the sub-chain and acts as a "bridge" that allows the user to interact between the Ethereum main chain and the sub-chain.

Then we create our sub-chains. Subchains can have their own set of consensus mechanisms—in this case, Proof of Authorization (PoA), a consensus mechanism that relies on trusted block producers. Block producers are similar to miners in workload proofs—they are nodes that accept transactions, generate blocks, and charge transaction fees. To make a simple analogy, suppose you are the only entity that generates the block—that is, your company runs several nodes, which are the block producers of our sub-chains.

Once the sub-chain is created or activated, the block producer commits to the root contract. This means that they are actually saying "I testify that the latest block in the sub-chain is X." These commitments are recorded in the Plasma root to prove the transactions that took place in the sub-chain.

Now that the subchain is ready, we can create the basic components of the trading card game. The card is based on the ERC 721 of the Ethereum backbone, which is transferred to the sub-chain via plasma root. This introduces a key point: plasma allows us to interact with Eita-based digital assets on a large scale. Then, we deploy the smart contract of the game application on the sub-chain, and write the game logic and rules into the contract.

Game users are actually just interacting with our sub-chains. They can hold assets (ERC 721 token), trade with Ether, play with other users, and never interact directly with the main chain. Because only a small number of nodes need to process transactions, the transaction costs will be much lower and the operation speed will be faster.

But how can it be safe?

By shifting more operations to the sub-chain, the main chain can handle more transactions. But how do you protect it? Is the transaction occurring on the sub-chain the final? After all, we just said that there will be a physical company controlling the generation of blocks. Isn't this centralization? Can this company steal your funds or game cards at any time?

Simply put, even if a company has 100% control over a sub-chain block, plasma provides you with a basic guarantee that you can take your funds and assets back to the main chain at any time. If a block producer has malicious behavior, the worst thing is that it will force you to leave the subchain.

Let's see what kind of malicious behavior the blockchain producers will have, and see what kind of countermeasures plasma will make.

First, imagine how a block producer will fool you by controlling your money by creating a fake new block. They are the only ones that have the power to generate blocks, so they can create blocks without following the rules of the blockchain. Like other blocks, they will also publish a commitment to include the Plasma root contract for the block.

As mentioned above, users are guaranteed and they can withdraw their assets back to the main chain. In this case, the user (or rather the application acting on their behalf) will detect the attempted theft and exit before the block producer attempts to use the assets they "steal".

Plasma also created a mechanism to prevent fraud from exiting the main chain. Plasma includes a mechanism by which anyone (including you) can issue evidence of fraud to the root contract to prove that the block producer is cheating. This fraud certificate will contain information about the previous block. According to the state transition rule of the sub-chain, the fake block does not conform to the previous state. If the fraud is confirmed, the sub-chain will be "returned" to the previous block. Even better, we built a system in which any block producer who signs a fake block will be penalized for losing a deposit on the chain.

But submitting evidence of fraud requires access to basic data, the actual history of the blocks used to prove fraud. What if the block producer does not share information about the previous block to prevent Alice from submitting evidence of fraud to the root contract?

In this case, Alice needs to withdraw her funds and leave the sub-chain. In fact, Alice submitted a “fund certificate” to the root contract. After waiting for a while, anyone can question her proof (for example, to prove that she spent the money in a later valid block), Alice's funds were moved back to the Ethereum main chain.

Finally, the block producer can review the users of the sub-chain. Block producers can effectively prevent users from performing any operations on the sub-chain if they wish. It is simply to withdraw all of our assets back to the main chain described above.

However, the withdrawal itself is also risky. If all users on the sub-chain want to take out all of their assets at the same time, the Ethereum main chain may not be able to withstand this pressure. There are also many techniques that can prevent this from happening, such as extending the response time of a withdrawal.

The fact is that a company that controls 100% of block generation rights is a very extreme situation and generally does not happen. That is to say, the sub-chain is decentralized like the public chain. Therefore, the risks mentioned in the appeal will be relatively small.

Now that we have talked about the state channel and Plasma, compare the two.

1) One difference is that when all users in the same channel agree to exit, the status channel can exit immediately. For example, if both Alice and Bob agree to close a channel and get their funds back, they can get back the assets immediately. This is not possible on Plasma. In Plasma, the user must wait for a while before exiting.

2) The status channel is also cheaper and more convenient than Plasma. This means that we can combine the two to establish a state channel on the Plasma subchain. For example, on an app, two users can make a series of small transactions. Creating a state channel on a sub-chain is cheaper and more efficient than trading directly on a sub-chain.

3) Finally, this article may have omitted some details. Plasma is still in its early stages, and you can take a look at V God's recently proposed "Minimum Feasible Plasma". There is also a Taiwan team that is also doing this. OmiseGo is also working in this direction.

3, Truebit

Truebit is an offline technology that helps Ethereum to do heavy calculations. The state channel and Plasma are expanding throughput, so this is the difference between Truebit. Truebit won't increase transaction throughput, but it will make the Ethereum-based application do more complicated things.

Some operations are too computationally expensive to perform on the chain. For example, verifying Simple Payment Verification (SPV) certification from other blockchains, this allows Ethereum Smart Contracts to "check" whether a transaction occurs on another chain (such as Bitcoin).

Imagine you need to perform some expensive calculations (like the SPV proof) on an Ethereum-based app. You can't simply use it as part of the Ethereum's main chain smart contract because SPV calculations are too expensive. In fact, all calculations at Ethereum are expensive because all nodes are always required to participate in the calculations.

However, you can pay someone (the solver) a fee and let it complete the chain calculation.

First, the solver deposits a fee into the smart contract, and then you inform the resolver of the demand. He calculates and then feeds the results back to you. If the calculation is correct, his deposit will be refunded. If the calculation is wrong (he makes a mistake or cheats), he will lose his deposit.

So how do we know that the result is not correct? Truebit uses an economic mechanism called "validation games." In essence, we have created an incentive mechanism that encourages “challengers” to verify the results submitted by the solver. If the challenger can verify the game and prove that the solver submitted a wrong result, they will be rewarded and the solver will lose their deposit.

Because the verification game is executed on the chain, it cannot simply calculate the result (this will destroy the purpose of the entire system, because if we can perform calculations on the chain, we do not need Truebit). Instead, we force the solver and challenger to determine the specific actions they disagree with. In fact, we are working hard to make the parties disagree with the results.

Once the operation is identified, it is enough to run on the Ethereum main chain. Then, we execute the details through smart contracts.

in conclusion

The Layer 2 expansion scheme has a common core: once there is a deterministic hard core provided by a public chain, we can use it as an anchor for a digital economy system that extends the effectiveness of blockchain applications.

I mentioned some examples above, which will give us a more specific understanding of the application scenario of the Layer 2 expansion solution. The economic mechanisms used in Tier 2 expansion schemes are often interactive games : they work by creating competition or “checking” motives for different participants. The blockchain application can assume that a given statement may be true because we have created a strong motivation for the other party to provide information that proves it is false.

In the status channel, the way we confirm the final state of the channel is to give the parties an opportunity to "rebut" the other party. In plasma, it is how we manage fraud evidence and withdrawals. In Truebit, it's how we ensure that the solver tells the truth – by giving the verifier an incentive to prove that the solver is wrong.

These systems will help address some of the challenges involved in scaling up large-scale global user bases. Some tools, such as state channels and Plasma, will increase the transaction throughput of the platform. Other tools, such as Truebit, will make it possible to open more new use cases by making more difficult calculations part of a smart contract.

These three examples represent only a small part of the digital economy expansion solution. We haven't even touched on "cross-chain" work like Cosmos or Polkadot. We should also expect to create new and unexpected Tier 2 expansion systems to improve existing models or to provide new trade-offs between speed, finality and cost.

More important than any particular Tier 2 expansion scheme is the further development of the underlying technology and mechanisms: the digital economy.

These Layer 2 expansion schemes need to be built on a programmable blockchain, such as Ethereum: you need a scripting language to write programs. For blockchains like Bitcoin, this is much more difficult (or in some cases essentially impossible) because these blockchains only provide limited scripting.

We can build a Layer 2 expansion solution on Ethereum and strike a balance between access speed, finality and cost. This makes the underlying blockchain more practical for a wider range of applications. For high value transactions, it is recommended to use the main chain. For trading digital collections, speed is more important, we can use Plasma. The Tier 2 expansion scheme allows us to make these trade-offs without sacrificing the underlying blockchain, maintaining decentralization and final certainty .

Author: L4 co-founder Josh Stark

We will continue to update Blocking; if you have any questions or suggestions, please contact us!