Original author: V God
Original translation & AMP; Proofread by Min Min & AMP; O sword
For many blockchain applications, trustworthiness is one of the most important features. Trustworthiness is the premise that the application does not work in a certain way, even if they will be driven by profit to do something unexpected in the future (and not make the application work out of expectation). Blockchain applications will never be completely trust-free, but some are far more trust-free than others. If we want to take solid steps towards trust minimization, we need to identify the levels of trust.
First, my personal definition of trust is simple: trust is an assumption about the behavior of others. Before an outbreak, you don't want to stay two meters away from someone because you're afraid they'll stab you suddenly. This is a kind of trust: on the one hand, trust in others not to run amok, and on the other hand, trust in the legal system's binding force on criminal ACTS. When you run a piece of code written by someone else, you trust them to be honest (either from a moral point of view or from a financial point of view), and at least enough people have audited the code to know it's bug free. Not growing your own vegetables is also a matter of trust: the belief that there will be enough people to produce food for money. You can trust different groups, and there are many types of trust.
In order to analyze the blockchain protocol, I will break down trust into four dimensions:
How many people do you need to act as you expect?
What is the total number of participants?
What motivations do you need these people to act as you expect them to? Are they altruistic or mercenary? Is there a need to avoid synergy between them?
If these assumptions are broken, how much damage is done to the system?
For now, let's focus on the first two. From the following figure, we can see more intuitively:
The darker the green, the healthier it is. Let's break down the following scenarios:
1:1: The whole system has only one actor. If the participant does behave as you expect, the system will work. This is the traditional "centralization" model, and this is the model we want to go beyond.
The dystopian world. All the participants in the system have to do what you expect them to do in order for the system to function properly, and if any of the participants fail, there is no backup plan.
N/2: N: That's how the blockchain works -- if most miners (or PoS verifiers) are honest, the blockchain works. Note that the larger N is, the more valuable N over 2 is. A widely distributed network of miners/verifiers is much more interesting than a blockchain controlled by a small number of miners/verifiers. However, we still want to get better security, because 51% of the attacks are still problematic.
1: N: Among the many participants, it only takes one participant to do what you expect, and the whole system will work. Any system based on proof of fraud falls into this category. The same is true for trusted Settings, although in trusted Settings, N is usually smaller. Note that the bigger the N, the better!
Very few: N: In a large number of participants, as long as a fixed number of a small number of participants do as you expect, the whole system will work. Data Availability checks fall into this category.
0: N: The system can function without relying on external actors. Self-validating blocks fall into this category.
Although all models except "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 (organisation) will behave as you expect, and believing that any one person will behave as you expect. "1: N" is closer to "0: N" than "N/2: N" and "1:1". One might think that the "1: N" model is similar to the "1:1" model in that both systems rely on one actor, but in reality they are very different: in the "1: N" system, if the actor disappears or commits a crime, a different actor is needed; If it's a 1:1 system, there's nothing you can do about it.
In particular, the correctness of even the software you're running often depends on the "very few: N" trust model to ensure that bugs in your software code will be spotted. When you look at this fact, trying to move from the "1: N" model to the "0: N" model is like installing a security door on a house with open Windows.
Another important difference is, if your trust assumption is broken, how much damage does it do to the system? Liveness Failure and Safety Failure are the two most common types of failures in block chain. An active failure is when you are temporarily unable to perform operations (e.g., withdraw COINS, package transactions into blocks, read data on the chain). A security failure is when something happens that the system wants to prevent (for example, invalid blocks are added to the blockchain).
The following is a list of some of the trust models used in 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 in the underlying blockchain. My assumption is that the community of Layer 2 is always smaller than the community of the underlying blockchain. In addition, what I call "active failure" refers specifically to a situation where tokens stick for a long period of time. An inability to use the system but being able to withdraw money immediately is not considered an active failure.
Channel class (including network state channels, lightning, etc.) : use "1:1" trust model to ensure that the active (your counterparty can temporarily freeze your money, but you can put money across multiple channels, so as to reduce negative effect), "N / 2: big N" model to ensure the safety, the attacker can steal your money) by 51%.
Plasma (with centralized operators) : Use a 1:1 model to ensure activity (operators can temporarily freeze your money) and an N/2: Big N model to ensure security (attackers can steal your money with 51% attacks).
Plasma (with semi-centralized operators such as DPOS) USES the "N/2: Small N" model for activity and the "N/2: Big N" model for security.
Optimistic Rollup: USES either a "1:1" or "N/2: Small N" model to ensure activity (depending on the type of operator) and an "N/2: Big N" model to ensure safety.
ZK Rollup: USES the "1: small N" model to ensure activity (if operator fails to package your transaction, you can get your money back, if operator fails to package your withdrawal transaction immediately, you can't package more transactions, you can withdraw your money with the help of any full node in the Rollup system). ; There is no risk of security failure.
ZK Rollup: No active failure risk or security failure risk.
Finally, there is the question of incentives: Do the participants you trust need to be very altruistic, generally altruistic, or rationalist in order to achieve the desired effect? By default, "fraud proof" requires that the participant is altruistic, but how much depends on the complexity of the calculation (see "Verifier dilemma"), and there are ways to modify the rules to make them rational.
If we add a way to pay for service, it is rational to help others withdraw money from ZK Rollup, so there is no need to worry about not being able to exit Rollup. At the same time, the risk to other systems can be mitigated if the entire community agrees not to accept blockchains created through 51 per cent attacks (by rolling back transaction history or reviewing blocks long ago).
Conclusion: If you hear someone say that a system "depends on trust," be sure to ask! Is the system a "1:1", "1: N" or "N/2: N" model? Does the system require altruism or rationalism among the participants? If it is altruism, how much does it cost the participants? If the assumption is broken, how long do you have to wait to get your money back? How many hours? A few days? Or will you never get it back? Once you know these questions, you can decide whether to use the system or not.
The original link
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
Related Articles
