For many blockchain applications, trust-free is one of the most important features. The so-called trustlessness means that the normal work of the application does not presuppose that specific participants behave in a specific way, even if they will act unexpectedly in the future driven by interests (it cannot make the application work out of expectations) . Blockchain applications can never achieve complete trust-free, but some applications are far more trust-free than others. If we want to take a solid step towards minimizing trust, we must first identify the level of trust.
First of all, my personal definition of trust is very simple: trust is an assumption of other people’s behavior. Before the outbreak, you will not deliberately keep a distance of two meters from others because you are afraid of someone stabbing you suddenly. This is a kind of trust: on the one hand, it is trusting others not to go violently, on the other hand, it is trusting the legal system’s binding force on illegal and criminal acts. When you run a piece of code written by other people, you believe that they are honest (whether from a moral or financial point of view), and at least enough people have audited the code and know it No bugs. Not growing your own vegetables is also a kind of trust: I believe that enough people will produce food to make money. You can trust different groups, and there are many types of trust.
In order to analyze the blockchain protocol, I will disassemble trust into four dimensions:
How many people do you need to behave as you expect?
What is the total number of participants?
What motives are needed for these people to act as you expect? Do they need to be altruists or profit-seekers? Is it necessary to avoid synergy between them?
If these assumptions are broken, how much damage will the system be?
Now, let us focus on the first two issues. Through the following figure, we can see more intuitively:
The darker the green, the healthier. Let us analyze the following situations in detail:
1:1: There is only one participant in the entire system. If this participant does act as you expect, the system will operate normally. This is the traditional “centralized” model and the model we want to surpass.
N:N: “Dystopian” world. All participants in the system must behave as you expect in order for the system to function normally. If any participant fails, there is no backup plan.
N/2:N: This is how the blockchain works-if most of the miners (or PoS validators) are honest, the blockchain can function normally. It should be noted that the larger N, the more valuable N/2. Compared to a blockchain controlled by a small number of miners/validators, a widely distributed network of miners/validators is much more interesting. Nevertheless, we still want to obtain higher security, because there are still 51% attacks.
1:N: Among the many participants, as long as one participant behaves as you expect, the entire system can operate normally. Any system based on fraud proof falls into this category. The same is true for trusted settings, but in trusted settings, N is usually small. It should be noted that the larger N, the better!
Very few: N: Among the many participants, as long as a fixed number of participants behave as you expect, the entire system can operate normally. Data availability check (data availability check) falls into this category.
0:N: The system can operate normally without relying on external participants. Self-verified block validity falls into this category.
Although models other than “0:N” are based on “trust”, there are huge differences between these models! There is a world of difference between believing that a particular person (organization) will behave as you expect, and believing that any one person will behave as you expect. Compared with “N/2:N” and “1:1”, “1:N” is closer to “0:N”. Some people may think that the “1:N” model is very similar to the “1:1” model, because both systems rely on one participant, but in fact they are quite different: in the “1:N” system, If this participant disappears or commits evil, just change another participant; if it is a “1:1” system, you can only do nothing.
In particular, it should be noted that even if the software you are running, its correctness usually depends on the “very few: N” trust model to ensure that when software code bugs, someone will find out in time. After understanding this fact, you will find that trying to switch from the “1:N” model to the “0:N” model is like installing a security door for a house with open windows.
Another important difference is that if your trust assumptions are broken, how much damage will the system be? On the blockchain, the two most common types of failures are liveness failures and safety failures. Active failure means that you are temporarily unable to perform operations (for example, withdrawing coins, packaging transactions into blocks, reading data on the chain). A security failure is a situation that the system wants to prevent (for example, an invalid block is added to the blockchain).
The following lists some of the trust models adopted by the blockchain Layer 2 protocol. I use “small N” to refer to the set of participants in the layer 2 system itself, and “big N” to refer to the participants of the underlying blockchain. My assumption is that the community of Layer 2 is always smaller than the community of its underlying blockchain. In addition, what I call “active failure” refers to the situation where the token is stuck for a long time. The situation where the system cannot be used but can be withdrawn instantly is not counted as an activation failure.
Channel class (including state channel, lightning network, etc.): Use the “1:1” trust model to ensure liveness (your counterparty can temporarily freeze your funds, but you can spread the funds across multiple channels to reduce the negative Impact), “N/2:big N” model to ensure security (attackers can steal your funds through 51% attacks).
Plasma (using a centralized operator): Use the “1:1” model to ensure liveness (the operator can temporarily freeze your funds), and the “N/2:big N” model to ensure security (the attacker can pass 51% Attack to steal your funds).
Plasma (using a semi-centralized operator, such as DPOS): Use the “N/2:small N” model to ensure liveness, and the “N/2:big N” model to ensure security.
Optimistic Rollup: Use the “1:1” or “N/2:small N” model to ensure activity (depending on the type of operator), and the “N/2:big N” model to ensure safety.
ZK Rollup: Use the “1: small N” model to ensure liveness (if the operator fails to package your transaction, you can get your funds back, if the operator does not immediately package your withdrawal transaction, you cannot package more transactions , You can withdraw money by yourself with the help of any full node in the Rollup system.); there is no risk of security failure.
ZK Rollup (enhanced light withdrawal): There is no risk of active failure and safety failure.
Finally, there is the question of motivation: In order to achieve the desired effect, the participants you trust need to be very altruistic, general altruism, or rationalism? By default, “Fraud Proof” requires participants to be altruistic, but the degree depends on the complexity of the calculation (see “Verifier Dilemma” for details), and there are many ways to modify the rules to make them rational.
If we add a way to pay for the service, then the behavior of helping others withdraw money from ZK Rollup is rational, so there is no need to worry about the problem of not being able to withdraw from Rollup. At the same time, if the entire community agrees not to accept the blockchain created by a 51% attack (rolling back the transaction history to a long time ago, or reviewing the block long ago), the risks of other systems can be mitigated.
Conclusion: If you hear someone say that a system “depends on trust”, be sure to ask! Is this system a “1:1” model, a “1:N” model or an “N/2:N” model? Does this system require participants to be altruistic or rational? If it is altruism, how much do participants have to pay? If the hypothesis is broken, how long do you have to wait to get your funds back? a couple of hours? How many days? Or will you never get it back? Only after understanding these issues can you decide whether to use this system.
