Dawn of Hybrid Layer 2 Protocols

Editor's Note: This article comes fromChain News ChainNewsEditor's Note: This article comes from

Chain News ChainNews

Chain News ChainNews

, Author: Vitalik Buterin, compiled by Lianwen, reproduced by Odaily with authorization.

The current Ethereum Layer 2 expansion solutions (mainly referring to Plasma and state channels) are moving from theory to practice. But at the same time, it is becoming more and more obvious that these technologies have inherent challenges, and there is still a certain distance from the mature Ethereum expansion technology.

To a large extent, Ethereum was successful because the developer experience on Ethereum was great: write a program, publish it, and anyone can interact with it. Designing a state channel or Plasma application, on the other hand, relies on a lot of explicit reasoning about the incentives and complexity of application-specific use-case development. State channels are suitable for specific use cases, such as multiple recurring payments between two traders or two game players (successfully implemented in Celer), but more general use cases still seem to be difficult. Plasma (especially Plasma Cash) can be used in payment scenarios, but there are certain challenges in implementing general-purpose use cases: even deploying a decentralized exchange requires customers to store more historical data, and deploying on Plasma Ethereum-style general-purpose smart contracts also seem to be very difficult.

But at the same time, a forgotten "semi-Layer 2" protocol class has reappeared - this type can not improve scalability, but can achieve a more generalized and secure model.

In a blog post published in 2014, I introduced the concept of "shadow chain", which is an architecture that publishes block data on the chain, but does not verify the block by default . Instead, blocks are tentatively accepted and then finalized after a period of time (say, two weeks or so). During these two weeks, the temporarily accepted block may be challenged, and the block is verified through the challenge. If the block is finally proved to be invalid, the chain where the block is located will be restored, and the original publisher's Security deposit will be deducted as penalty. The contract does not track the complete state of the system, only the state root, and users themselves can process the data submitted to the blockchain from beginning to end to calculate the state.

A recent proposal called ZK Rollup uses ZK-SNARKs to verify the validity of blocks. Although there is no challenge period, the same effect can be achieved.

Above: Anatomy of the ZK Rollup package published on the chain. Hundreds of "internal transactions" that affect the state of the ZK Rollup system (i.e., account balances) are compressed into a package, which contains each internal transaction accounting for about 10 bytes in size, and the key used to prove the full validity of the related transfer process. (about 100-300 bytes in size) SNARK, about 100-300 bytes in size.

In the above case, the main chain is used to verify data availability, but does not (directly) verify block validity or perform any significant computations (unless a challenge is raised). Therefore, this technology does not have any key advantages in terms of capacity expansion, because the data load on the chain will eventually become a bottleneck, but it is undeniable that it is still a very important means.

Data is cheaper than computation, and there are many ways to significantly compress transaction data—mainly because the vast majority of data in transactions is signature data, and many signatures can be compressed into a single signature through multiple forms of aggregation. ZK Rollup promises to process 500 transactions per second, which is 30 times more efficient than Ethereum itself, because it compresses each transaction to only 10 bytes, and the validity of the transaction is verified by zero-knowledge proof, so there is no Signature needs to be included. On the other hand, similar throughput can be achieved in "shadow chains" using BLS aggregate signatures (similar to Optimistic Rollup, a new architecture recently released by Ethereum Casper core developer Karl Floersch). The upcoming Istanbul hard fork will reduce the gas cost of data from 68 units per byte to 16 units per byte, while also quadrupling throughput (i.e. over 2000 transactions per second).

So, what are the benefits of data on-chain techniques like ZK/Optimistic Rollup compared to off-chain scaling technologies like Plasma?

First, ZK/Optimistic Rollup does not require a "semi-trusted" operator. In ZK Rollup, because the validity of the transaction is verified by cryptographic proofs, the submitter of the package does not actually have much way to "do bad things" (of course, according to the settings, malicious submitters may cause the system to Pause for a few seconds, but that's about as much damage as they can do to the system). In Optimistic Rollup, a malicious committer can publish a "bad block", but the next committer can immediately challenge that block before publishing their own. In ZK Rollup and Optimistic Rollup, enough data will be released to the chain, allowing anyone to calculate the complete internal state, all submitted deltas need to be processed in order, and there is no "data withholding attack" that cancels this property ". In other words, becoming an operator can be completely "permissionless", and the required deposit (only 10 ETH) is only used for anti-spam purposes.
Secondly, the implementation of Optimistic Rollup is more generalized. The state transition function in the Optimistic Rollup system can be used to perform more general calculations within the gas limit of a single block (including Merkle branches that provide the state part required to verify the transition period). In theory, ZK Rollup can also achieve general-purpose computing in the same way, but in practice, it is very difficult to use ZK SNARKs for general-purpose computing (such as executing in EVM), at least so far.

Again, Optimistic Rollup is easier to build clients because it requires less Layer 2 network infrastructure, and a lot of work can be done by simply scanning the blockchain.

However, what are the advantages of something like ZK/Optimistic Rollup? In fact, this is a highly technical problem, also known as the data availability problem. (For details, please refer to the explanation document

https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding and explaining video: https://www.youtube.com/watch?v=OJT_fR7wexw)

Basically, there are two ways to "cheat" in a Layer 2 system: the first is to publish invalid data to the blockchain, and the second is not to publish data at all (for example, in Plasma, the Plasma new block's The root hash is published on the main chain, but the block content is not disclosed to anyone).

Publishing invalid data is actually very easy to deal with, because once the data is published on the chain, there are many ways to determine whether it is valid, and the submitted invalid data will be marked as invalid, and the submitter will be severely punished for this. On the other hand, unavailable data is more difficult to deal with, because it is impossible to detect unavailability even if challenged, and it is impossible to pinpoint whose fault these unpublished data are, especially when the data is retained by default. , only displayed on demand if some authentication mechanism attempts to verify its availability. This is illustrated in the Fisherman's dilemma, where in a challenge-response game it is impossible to distinguish between malicious submitters and malicious challengers:

Above: Fisherman's Dilemma. If you only start looking at the given specific data at time T3, then you have no way of knowing whether you are in Case 1 or Case 2, and therefore you don't know whose fault it is.

Plasma and state channels effectively solve the "fisherman's dilemma" problem by pushing the problem onto the user: if you are a user and decide to interact with another user (a counterparty in a state channel, or an operator in Plasma ), assuming that user doesn't send you the data they should, then you're out and moving on to the next counterparty/operator. The fact that you, as a user, own all previous data and all transaction data signed by you allows you to prove in the blockchain that you own assets in the Layer 2 protocol, thereby safely taking those assets out of the system. In addition, you also need to have (previously agreed) operational proof of receiving assets, and at the same time, no one else can prove that you sent the relevant assets to others, then you have obtained this asset.

This technique is indeed elegant, but it relies on a key assumption: each state object has a logical "owner", and without the owner's consent, the object state cannot be changed. So, this technique works for payment transactions based on unspent transaction outputs (UTXO) (but not payment transactions based on the account model, because in this case you can edit other people's account balances upwards without their consent , which is why the Plasma of the account model is so difficult), and can even be used in decentralized exchanges, but this "owner" attribute is far from enough. Some applications (such as Uniswap) do not have a natural owner, and even in those applications that do, there are often multiple people who can legally edit the object in question. There is no way to allow arbitrary third parties to withdraw assets without introducing the possibility of a denial of service (DoS) attack, since no one can prove whether the issuer or submitter was at fault.

In addition, Plasma and state channels have some other problems respectively. For those users who have not yet joined the state channel, off-chain transactions are not allowed. Plasma requires users to store a large amount of historical data, which becomes even larger when different assets are intertwined (for example, the condition of one asset transfer is based on another asset transfer, as in having a single-stage ( single-stage) as happens in decentralized exchanges with a buy order mechanism).

Because the Layer 2 technology of data-on-chain computation-off-chain has no data availability problem, there is no such weakness. ZK Rollups and Optimistic Rollups take great care to put enough data on-chain to allow users to compute the full state of the Layer 2 system, ensuring that if any participant disappears, a new one can easily take its place. The only problem with Layer 2 technology is verifying computations without doing on-chain computations, but that's actually an easy problem to solve. Moreover, scaling will bring greater benefits: each transaction in ZK Rollup is about 10 bytes, and Optimistic Rollup can reach a similar level by using BLS aggregate signatures. Theoretically, it can reach up to 500 transactions per second, and after the Istanbul upgrade, the indicator number can reach 2000 transactions per second.

But what if you want higher scalability?

In fact, there is a large middle ground between Layer 2 on-link and Layer 2 off-link protocols, and many hybrid solutions take advantage of both. As a simple example, by publishing an order matching map (less than 4 bytes) on the chain, it is possible to prevent the historical storage explosion problem of the decentralized exchange deployed on Plasma Cash:

Above left: Plasma Cash users who own a token need to store historical data;

Above: Plasma Cash users need to store historical data when owning a token and the token is obtained through an atomic swap;

Above right: Plasma Cash users need to store historical data if the order matching is published on the chain;