Science | Layer 2 Solution Overview: From Status Channel to Roll Up

Although blockchains have become more widely used, the load on contemporary protocols is very limited, so many Layer 2 protocols have emerged, such as state channels, sidechains, Plasma, and Roll Up. This article delved into the technical details and advantages and disadvantages of each of these solutions.

The core idea of ​​all Layer 2 solutions is to allow multiple participants to implement secure interactions in some way, without having to publish the transaction on the main chain (ie Layer 1), but to some extent use the main chain as an arbitration. To ensure its security.

Different Layer 2 solutions have different characteristics and advantages and disadvantages. My personally optimistic Layer 2 solution is Roll Up, which is explained in more detail below.

• "Old World" Deutsche Bank layoffs, "New World" bitcoin broke through 12,000 US dollars
• Weekly market report | overall market value, transaction volume both callbacks, BTC weekly maximum increase of 23.29%
• Morning market: Bitcoin broke through 12,000 US dollars to keep going up, even the market is just around the corner

 

State channel

Let's take a look at the entry-level Layer 2 solution – the payment channel. The payment channel is the most widely used Layer 2 solution today. For example, the lightning network is built on the payment channel technology.

The payment channel is a concrete example of the big concept of the status channel. A review of the history of state channels can be found on the wiki. A state channel is a protocol that secures a group of participants (usually two participants) for secure chain transactions, where the payment channel is dedicated to payment. The payment channel agreement is as follows: Two participants each lock the margin on the chain through a chain transaction, say, $10 worth of bitcoin. Once the lock is completed, the participants can send each other a status update of [Round, Amount, Signature] to realize the transfer without having to interact with the main chain, as long as the balances of both parties are still positive.

Once one of the participants wants to stop using the payment channel, an “exit” operation can be performed: the final status update is submitted to the main chain, and the settled balance is returned to both parties who initiated the payment channel. The main chain can verify the validity of the status update by verifying the signature and the final balance, thereby preventing the participant from using the invalid status to exit the payment channel.

One problem with this "exit" mode is that the main chain cannot verify that the payment channel has submitted all transactions, that is, whether new status updates no longer appear after the status update has been submitted. We can consider such a scenario:

Assuming that Alice has $11 in the initial state and Bob has $9, Alice sends a status update to Bob—transfers Bob for $7, waits for Bob to provide her services, and then exits before $7 has not arrived. The payment channel. The "exit" transaction is considered valid because the main chain does not know that there are additional status updates.

The solution to this problem is to set aside a "challenge period" for Bob after Alice initiates the exit transaction. During this time, Bob can submit a status update for outstanding billing, which contains Alice's signature, and the number of rounds is higher than the status update Alice submitted upon exit. In the above example, Bob can submit the last status update during the challenge period, that is, Alice transfers a $7 status update to him and asks for a $16 balance instead of being left by Alice for only $9. .

Although the current exit mechanism is designed to be very secure, the main trouble is that participants may have to wait for a longer period of time, usually 24 hours, to exit, and they need to monitor the main chain frequently (at least once per exit period). Make sure their counterparty does not exit using one of the past states. The task of monitoring the entire network can be delegated to third parties through WatchTowers technology. More articles about Watchtower can read this and this article.

In order to avoid such unnecessary waiting, the two parties can achieve "collaborative shutdown" through many implementations. Among them, participants can sign an "end certificate." With this proof, the other party does not have to wait for the end of the challenge period to exit.

Payment channels can be used for a wide range of state transitions, not just for payment, as long as the backbone can verify the correctness of these state transitions. For example, the status channel can be used to play chess, and the player can send their respective moves as a transaction to the other party.

Although there are inconveniences, the status channel has been widely used in payment, games and other use cases, because this technology has immediate certainty (as soon as the counterparty confirms, the status update can be finalized), without the participant paying the pledge and Other fees than the withdrawal fee are relatively simple in structure.

Although the general definition of the state channel is simpler and takes into account all extremes, it can prevent one party from illegally possessing the other's assets, but it is more complicated to implement. A video from the Whiteboard series comes from Tom Close of the Magmo team, which provides an in-depth analysis of the complexity of building secure state channels.

State channel network

Another disadvantage of the status channel is that it can only be opened between two participants. You can maintain a status channel between multiple participants through the N/N multi-signing mechanism. In contrast, the Layer 2 solution with the same functionality is ideal, allowing participants who do not have a status channel to trade directly.

There is also an interesting way to set up the status channel. If there is a status channel between Alice and Bob, and there is also a status channel between Bob and Carol, then Alice can safely and automatically transfer to Bob via Carol. This allows you to build a complete stateful channel network that allows large batches of participants to trade with each other without having to open a state channel between each pair of participants.

This is the design idea of ​​Lightning Network. One video in the Whiteboard series is Dan Rabinson's Interledger, which provides an in-depth analysis of the lightning network design, which can be viewed here.

Side chain

The core idea of ​​the sidechain is to build a completely independent blockchain, with its own verifier and operator, which can transfer assets to and from the main chain, and will selectively send snapshots of the block headers to the main chain, thus preventing the points. The fork is produced. With these snapshots, it is possible to effectively prevent forks, even if the verifier on the side chain colludes to launch a fork attack.

As you can see from the figure above, the sidechains generate blocks and send their snapshots to the main chain. A so-called snapshot is a block hash stored on the main chain. The fork selection rule on the side chain is that the legal chain must be built on the last block that has been snapshotted. In the case shown above, a snapshot of block A has been sent to the main chain, even if the verifier on the side chain colludes, trying to generate a longer A'<-B'<-C after block A is generated. The chain will launch a double flower attack, and participants on the side chain will ignore this longer chain.

If the participant wants to transfer the assets on the main chain to the side chain, they will “lock” the assets on the main chain and provide proof of the lock to the side chain. If the asset on the main chain is to be unlocked, an "exit" transaction is initiated on the side chain and an exit certificate is provided after the transaction is packaged with the side chain.

Although the sidechain can take advantage of the security of the main chain to prevent forks, the verifier can still use collusion to launch another attack called invalid state transition. The idea behind this kind of attack is that it is impossible for the main chain to verify all the blocks on the side chain. (It really doesn't make sense to do this side chain. The side chain is that you want the main chain not to verify all transactions). Therefore, if there are more than 50% or 66% (depending on the sidechain architecture) of the certifier collusion, they can create a completely invalid block, steal the assets of other participants, and send a snapshot of this block. By the main chain, launching and completing an “exit” transaction, you can successfully steal these assets.

We have previously written an overview of the problem of invalid state transitions under the sharding mechanism. This problem corresponds one-to-one to the side chain context, the side chain is equivalent to the fragment in the overview, and the main chain is equivalent to the beacon chain in the overview.

The overview also mentions a solution to avoid invalid state transitions, but it has not yet been implemented. Most side chains are based on the assumption that the number of convictors is not more than 50% (or 66%).

Plasma

Plasma is a technology that can implement "unregulated" sidechains. In other words, even if all the verifiers on the sidechain (often called the "plasma chain") collude to do evil, the assets on the plasma chain are safe and can Return to the main chain.

The simplest plasma design, often called Plasma Cash, supports only simple non-homogeneous tokens, and the assets transferred per transaction can only be a specific constant. The way Plasma Cash works is shown below:

Each block contains a sparse Merkel Tree whose leaf nodes contain changes in ownership of a certain token. Take the above picture as an example. A total of 4 tokens are in circulation. In block B, tokens 1, 3, and 4 are not handed over (shown as empty in the leaf node), and token 2 is transferred to Alice's hands. If block D contains a transaction signed by Alice to transfer token 2 to Bob, then token 2 in block D will be transferred from Alice to Bob.

After a token is transferred from the main chain to the Plasma chain, if one party wants to transfer the token to the other party, a complete history of the token is required. In the above example, if Bob wants to transfer token 2 to Carol, then the previous transaction in each block will be recorded as an entry in the transaction. If there has been a change of ownership before, the relevant Merkel will be required. The proof is recorded, and the negative is recorded as a null value.

The Plasma chain sends a snapshot of all block headers to the main chain, and Carol can verify that all Merkel certificates match the hash values ​​previously sent to the main chain through the snapshot, and whether ownership changes in each block are effective. Once the transaction is packaged into chunks and placed on the plasma chain, Bob's entry of token 2 to Carol is recorded on the Merkel tree, and Carol becomes the owner of token 2.

Because Plasma is built on the assumption that operators can conspiracy at any time, users can't just exit immediately (because the state snapshot hash value proposed by the plasma operator cannot be trusted), and an exit is required. mechanism. Although the architecture we discussed above is relatively simple, the exit mechanism is very complicated. One of the Whiteboard series videos was shared by Georgios Konstantopoulos from the Loom Network, which provides an in-depth analysis of the technical details of Plasma Cash and introduces the exit mechanism used by the Loom Network. It also mentions an example where operators can hide data by hiding Stealing coins from honest participants or launching an attack (for details, please look at 41:40 in the video.) After that, Dan Robinson proposed a simple exit mechanism to solve this problem. It was then discovered that this mechanism could be broken by reordering the blocks.

All in all, the biggest advantage of Plasma is that the tokens stored on the plasma chain are very secure. No matter what happens, the plasma operator (before or after the honest participant receives the token) creates an invalid state transition, the plasma operator initiates a custody attack, and the plasma operator completely stops the block, honestly Participants can be sure that they can retrieve the token. In the above case, or in general terms, in any case, the token will not be lost.

The disadvantage is that the complete history of the token must be provided at the time of transfer of the token, and the exit mechanism is very complex (and related inference processes).

For more technical details, see the shared video of the Loom Network team mentioned above and the shared video from Ben Joines from the Plasma team. Among them, Ben talks about Plasma CashFlow, a more complex Plasma Cash design that can handle any amount of transactions.

Roll Up

As I mentioned in the discussion of sidechains, one way to solve the problem of invalid state transitions in sidechains is to provide cryptographic proofs to prove that each state transition was correct before. Recently, Matter Labs built a technology called Roll Up based on this method, and its idea was originally proposed by Barry White Hat on ethresear.ch.

Roll Up is actually a side chain, so it generates blocks and sends a snapshot of those blocks to the main chain. However, operators on Roll Up do not need to trust. That is to say, Roll Up assumes that the operator can make malicious actions such as stopping the block, generating invalid blocks, and concealing data at any time.

Similar to a normal side chain, if a snapshot of a block has been sent to the main chain, the operator on Roll Up can only launch a fork attack after this block. Therefore, once a snapshot of a block is sent to the main chain, the block is finalized, as is the block that took the snapshot on the Roll Up chain.

In order to avoid state validity issues, whenever a Roll Up operator wants to take a snapshot of a block, it must provide a SNARK (simple non-interactive knowledge proof) that the proof chain has executed using a related set of transactions. A valid state transition. The following figure is an example:

There are three blocks on the Roll Up chain: A, B, and C. Their snapshots correspond to blocks X, Y, and Z on the main chain. At each point in time, the main chain only needs to store the latest state of Merkel root on the Roll Up chain. At the time of the snapshot of block A, the transactions sent to the main chain include:

1. Merkel root h (S2) of the new state S2.

2. The complete status data of S2, or all transactions in the block.

3. A zk-SNARK, which proves that all transactions between the state hash h(S1) and the state hash h(S2) are valid, and these transactions match the data provided in (2). The transaction confirms that zk-SNARK is valid and stores a new Merkel root h(S2) on the chain. The important thing is that although the transaction does not store the complete data in A in the state, it will be saved in the call data for later recall.

In fact, storing the complete block in the call data is somewhat a bottleneck, but it can solve the data availability problem. Currently, Roll Up built by Matter Labs takes 1 minute to calculate the SNARK of a transaction (multiple transactions can be calculated in parallel), each transaction consumes 1K gas and occupies 9 bytes of call data on the main chain.

Under this design, the operator cannot do other malicious acts other than offline:

1, can not conceal the data, because the snapshot of the block must be submitted to the complete block or complete state as proof, and verify that the transaction content is correct, then the transaction content will be stored in the call data on the main network.

2. Blocks with invalid state transitions cannot be generated because a zk-SNARK must be submitted to prove the correctness of the state transition, while invalid blocks cannot calculate zk-SNARK.

3. A fork attack cannot be initiated because the fork selection rule always recognizes the chain in which the most recently taken snapshot is located, even if the chain is not the longest chain. Although this Layer 2 solution does not significantly increase the storage space in the call data, the amount of writable storage actually consumed is constant (and very small), and the cost of chain verification is as low as 1k gas/tx, which is the main chain transaction. 1/21.

It is important to assume that the operators on Roll Up work together to achieve an immediate exit without involving an exit mechanism. These features make the Roll Up chain one of the hottest Layer 2 solutions available today.

Conclusion

I am currently developing a Layer 1 fragmentation protocol called Near. A common misconception is that the Layer 1 fragmentation protocol competes with the Layer 2 expansion scheme. In fact, this is not the case, the implementation of the fragmentation protocol will not affect the use of the Layer 2 expansion solution.

Designed for specific use cases, Layer 2 delivers higher throughput while maintaining lower cost, even with significant improvements in the scalability of the Layer 1 blockchain.

Original link:

Https://ethfans.org/posts/layer-2-from-state-channel-to-roll-up

Author: Alexander Skidanov

Translation & Proofreading: Min Min & A Jian

Thanks to Jones (Plasma Group), Tom Close (Magmo), Petr Korolev, and Georgios Konstantopoulos for reviewing the first draft.

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