Vitalik: The same technique on Layer-2 and Layer-1

In many cases, the proposed Layer-1 improvement to improve scalability (that is, the modification of the blockchain protocol or the way the client works) and the Layer-2 improvement (which is widely used to spread this) The terminology; all that can be improved from the application layer design pattern to improve scalability can be counted as the same thing. This post will consider these cases with some examples and intuitive knowledge.

Stateless client

See The Stateless Client Concept (Editor's Note: Chinese translation at the end of the article) for background information on stateless clients. To summarize, the stateless client works by letting the entire node store only the root hash value of the state, using the Merkel branch sent with the block to prove that the state read and write has been executed correctly.

However, stateless clients can be implemented in two ways, one is the modification of the blockchain protocol (for example: https://medium.com/@akhounov/> error proof

Optimistic rollup works by letting the system store a series of historical state roots; adding a new state for a period of time (for example: 1 week) before finalizing the new state. When a new "package" containing some transactions is submitted to the rollup contract, the transactions (which refresh the Layer-2 state) will not be verified on the chain (although the availability of these transactions will be implicitly verified because they Both have to be packaged in this chain transaction; instead, just add the state root to the list. However, if an external observer finds that some packages are invalid (that is, the state roots claimed in these packages do not match the state that should be generated after executing the block based on the previous state and honestly), they can submit a challenge. If and only if so, the package will actually execute on the chain; if the package proves to be invalid, then the package and its subsequent state will be rolled back.

The above model is the so-called " Fraud proofs ". The proof of error works by default: the client does not verify the state (although they still need to download all the blocks to verify the availability), but instead accept the block; only when the client receives the message on the network, This includes the Merkel proof, which indicates that a particular block is invalid and will reject the block.

• V Shen Shenzhen 飙 Chinese: It is difficult to establish the advantage of the alliance chain. The current public chain is not enough to support high-frequency application development.
• Edgeware main network failed to start, the development team did not change the test network BUG?
• Babbitt column | Some thoughts about governance: always a few people have the final say

Obviously, the same mechanism (by default, downloading blocks but not checking content, only checking when someone sends an alert) can be used in the Layer-2 scenario or as an improvement to client efficiency in Layer1. One thing to note, however, is that if you want Layer-1's proof of error to have the same characteristics as rollup, the consensus on the data and the consensus on the state need to be a separate process. Otherwise, the node that created the block needs to verify all of the most recent blocks before releasing its block (because there may not be enough time to get proof of error), which may limit the gain of scalability.

Signature aggregation

Techniques like BLS signature aggregation can compress many signatures into one, greatly saving data and some computational overhead (as opposed to computational, huge savings in data storage that make it combined with false proofs) Can have very powerful performance). These techniques can be used on a chain to combine all transactions within a block into one transaction. These techniques can also be used at the application layer to allow many transactions to be packaged into a single package through a transaction packaging mechanism. A signature checker verifies the signature based on the hash value of all transactions and the sender's public key claimed in the transaction. Perform the transaction independently.

SNARK / STARK

SNARK and STARK can eliminate the need for the client to re-execute long-term calculations because its verification requires only a simple proof. This can also be done on layer 1 (see: Coda) or on layer 2 (eg ZK Rollup ).

Implementing vs in layer 1 in layer 2

Implementing on Layer 1 has the following advantages:

• It “retains identifiability” for the chain because the default infrastructure understands the scalability solution and explains what happened (although the standardization of generic Layer-2 technology can also provide this to some extent)
• It reduces the risk of fragmentation of the Layer-2 solution
• It allows the network to organize the infrastructure around the solution, for example, to automatically update the certificate in response to new blocks; the transaction is resistant to DoS attacks;
• In the case of sacrifices, it provides more freedom of choice for nodes , and nodes can consider their own needs. For example, some clients may store all state and minimize bandwidth, while other clients may verify the block statelessly and accept the bandwidth loss caused by doing so (VPSes may be compared to home computers here) Choose a different option). As an option, some clients may use error-based authentication to save money, while others may verify all states to maximize their security level.

Implementation on layer 2 has the following advantages:

• It leaves room for future innovations that do not require a hard-forked blockchain
• The complexity of the consensus layer can be minimized, especially when multiple scenarios are required for different scenarios. This is a big advantage.
• Users can therefore benefit from applications that have strong assumptions (eg, trusted initial settings) without having to introduce these assumptions into the consensus security construct (although sometimes this can be done on Layer 1)
• When it comes to trade-offs, it gives the application more freedom of choice, and the application can pick the solution to suit its needs. Some applications can run on the chain while others can run in the rollup

Other key points

The scalability gains obtained from Layer 1 and Layer 2 that depend on the same underlying behavior are generally not achievable . For example, the scalability gains obtained using error proofs and the scalability gains obtained using rollups do not overlap each other because they implement the same mechanism at all, so if you use rollups, you get 10000 tx/sec at the base layer. It is safe to use error proof to reach 1000 tx/sec, and it is safe to use only erroneous proof to get 10000 tx/sec on the same base layer.

Doing the same thing on Layer 1 and Layer 2 can lead to unnecessary infrastructure bloat, so it's often reasonable to choose one of the two. For example, if you use Layer 2's stateless contract regardless of the usage, then this will make the Layer-1 state extremely expensive, and you can't effectively implement the layer-2 solution. Therefore, keep the state small and avoid the layer. 1 You also need to build a stateless client.

The same thing to note is that data availability is the only security assumption that can be resolved on Layer 1, but on Layer-2, which can only rely on substantial relaxation (eg, assume that another group of participants is honest. Most) to provide things. This is because in data surrogate or other alternative systems where other blocks and erasure codes are available to reconstruct a block, block refactoring relies heavily on the randomness of the client side, which is very It relies heavily on the randomness of the client side, and the randomness is different for different clients and cannot be repeated on the chain.

in conclusion

The desire to continue to innovate in Layer 2 is an important argument that drives me to offer a heavyweight Layer-2 design for eth2, which minimizes the features provided by Layer 1 (eg, keeping the state small). This way, a stateless client is not needed, and a stateless contract is enforced on L2). However, because of some needs, we want to provide an explicit tool in Layer 1. For the above reasons, the most important thing should be the availability of data in Layer 1 of the generic extensible blockchain, which is why eth2 is fully implemented instead of building a heavyweight Layer-2 on the existing eth1 chain. The main reason for the road map.

(Finish)

Original link: https://ethresear.ch/t/cases-where-the-same-thing-can-be-done-with-layer-1-and-layer-2-techniques/6111 Author: Vitalik Buterin translation & Proofreading: haiki & Ajian

(This article is from the EthFans of Ethereum fans, and it is strictly forbidden to reprint without the permission of the author.

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