Ethereum Layer 2 expansion, why V God prefers ZK rollup?
Editor's Note: This article comes fromBabbitt Information (ID: bitcoin8btc)Editor's Note: This article comes from
Babbitt Information (ID: bitcoin8btc)
Babbitt Information (ID: bitcoin8btc)
, Author: Vitalik Buterin, translation: free and easy, published with permission.
One of the most valuable features of many blockchain applications is trustlessness: the application can continue to function in the intended way without relying on certain actors to behave in a certain way (even though their interests may change and prompting them to behave in some different and unexpected way in the future). Blockchain applications are never completely trustless, but some are closer than others. If we're going in the direction of trust minimization, then we need to be able to compare different levels of trust.
First, my simple definition of trust is this: trust is the exercise of any assumptions about the behavior of others. Before the pandemic, if you walked down the street without making sure you kept a two-meter distance from strangers, and they wouldn't suddenly pull out a knife and stab you, it was a matter of trust: both sides believed that people rarely fully Insanity, to believe that those who run the legal system will continue to provide strong measures against such behaviour. When you run a piece of code written by someone else, you can trust that they wrote it honestly (either out of a sense of decency or a financial interest in maintaining their reputation), or at least that enough people checked it out, and found loopholes. Not growing your own food yourself is also an act of trust: You have to trust that enough people will realize that it’s in their interest to grow food so they can sell it to you. You can trust people of different sizes, and there are different kinds of trust.
For analyzing blockchain protocols, I tend to divide trust into four dimensions:
How many people do you need to behave according to your expectations?
how many people?
What motivation do these people need to behave? Do they need altruism, or are they just looking for profit? Do they need coordination?
How badly would the system fail if these assumptions were violated?
Now, let's focus on the first two, we can draw a graph:
The greener the color in the picture, the better it is. Let's explore the trust categories in more detail:
1 of 1: There is only one actor, and the system will only work properly if that actor behaves as you expect. This is the traditional "centralized" model, and this is what we hope to try to replace.
N of N: A dystopian world where you rely on a whole bunch of actors, and all of them need to work as expected for everything to work, and if any one of them fails, it means there is no fallback personnel.N/2 of N: This is how blockchains work, if the majority of miners (or PoS validators) are honest, then the blockchain will work. Note that the larger N gets, the more valuable N/2 of N becomes. A blockchain with a small number of miners/validators dominating the network is less interesting than a blockchain with a wide distribution of miners/validators. That said, we would even like to increase this level of security against potential 51% attacks.1 of N: There are many participants, as long as at least one of them works as you expect, the system will work normally. Any system based on fraud proofs falls into this category, as do trusted settings, although N is usually smaller in this case. Note that you do want N to be as large as possible!
Data Availability Check
Apart from"0 of N"falls into this category."1 of N"Apart from"N/2 of N"or"1 of 1"Models in all categories other than , can actually be considered "trust", but they are very different from each other. Trusting that a specific person (or organization) will work as expected is very different from trusting someone anywhere to do what you expect. It can be said,"0 of N"than"1 of 1"or"few of N"closer to
. Whereas a "1-of-N" model might feel like a "1 of 1" model, as if you were trusting a single actor, the reality is quite different: in " 1-of-N” model. If the actor you're working with disappears or goes bad, you can switch to another actor while in
In a model system, encountering this situation means that the system is finished. In particular, note that even the correctness of the software you are running often depends on a
Trust the model to ensure that if there are bugs in the code, someone will find them and fix them.
Another important distinction: How will the system fail if your trust assumptions are broken? In blockchains, the two most common types of failures are liveness failures and security failures. The so-called liveness failure means that you are temporarily unable to do what you want to do (such as withdraw coins, get a transaction contained in a block, read information from the blockchain). A security failure, on the other hand, occurs when some activity occurs that the system is actively trying to prevent (e.g., the blockchain contains invalid blocks).
The following are examples of trust models for some blockchain Layer 2 protocols. Among them, "small N" refers to the set of participants of the Layer 2 system itself, while "Big N" refers to the participants of the blockchain, and I assume that the community of the Layer 2 protocol is always smaller than the main chain itself. I also limit the use of the term "liveness failure" to situations where coins are stuck for a long time. It is no longer possible to use the system, but being able to take it out almost immediately is not considered a failure of activity.
Channels (including state channels and the Lightning Network): live trust is a "1 of 1" model (your counterparty can temporarily freeze your funds, although this risk can be mitigated if you spread coins across multiple counterparties ), the security trust belongs to the "N/2 of big N" model (block chain 51% attack can steal your coins);
Plasma (assuming a centralized operator): active trust belongs to the "1 of 1" model (the operator can temporarily freeze your funds), security trust belongs to the "N/2 of big N" model (blockchain 51% attack );
Plasma (assuming semi-decentralized operators, such as DPOS): active trust belongs to the "N/2 of small N" model, and security trust belongs to the "N/2 of big N" model;Optimistic rollup: Active trust belongs to the "1 of 1" or "N/2 of small N" model (depending on the operator type), and security trust belongs to the "N/2 of large N" model;ZK rollup: active trust belongs to the "1 of small N" model (if the operator fails to include your transaction, you can withdraw coins, if the operator fails to include your withdrawal immediately, they cannot generate more batches , you can use any full node of the rollup system to withdraw funds yourself), ZK rollup has no risk of security failure;
Light Extraction EnhancementsVerifier's Dilemma): No activity failure risk, no security failure risk;
Finally, there is a question about incentives: do the participants you trust have to be very altruistic to behave as expected, or just slightly altruistic, or rational enough? Finding fraud proves that the "default" is somewhat altruistic, although how altruistic it is depends on computational complexity (cf.
