Vitalik Buterin's Handwriting: The Philosophy of Blockchain Verification

Editor's Note: This article comes fromGolden Finance, reprinted by Odaily with authorization.

Editor's Note: This article comes from

Golden Finance

, reprinted by Odaily with authorization.

Vitalik Buterin, the co-founder of Ethereum, published the paper "The Philosophy of Blockchain Verification" on his personal website on August 17. Jinse Finance compiled the paper as follows:

One of the most powerful features of a blockchain is the ability to independently verify each part of the blockchain's execution. Even if a majority of blockchain miners (or validators in a proof-of-stake blockchain) are taken over by an attacker, if that attacker tries to push invalid blocks, the network will simply reject those blocks. Even if users haven't validated those blocks within a certain amount of time, they are potentially automatically warned, and can check if the attacker's blockchain is invalid and automatically reject those blocks before accepting a chain according to the rules .

But how much validation do we really need? Do you need a hundred independent validators, or a thousand independent validators? Do we need a culture where every normal person in the world runs software to check every transaction? Solving the above problems will be a very important challenge if we want to build a blockchain with a consensus mechanism that is better than the single proof-of-work chain originally created by "Satoshi Nakamoto".

secondary title

Why does the blockchain need to be verified?

Validating the blockchain is very beneficial to users for two main reasons:

1. First of all, verifying the blockchain maximizes the chances that nodes can correctly determine to speak on the canonical chain. The valid blockchain with the most miners/validators supporting that chain" (e.g., the "longest valid chain" in Bitcoin). Invalid chains are by definition rejected, and if a choice is made between multiple valid chains, the chain with the most support from miners/validators wins. So if you have a node that can verify all the validity conditions, thereby detecting which chains are valid and which are not, you maximize your chances of correctly detecting the canonical chain.

2. Second, there is a deeper reason to verify the validity of the blockchain: Suppose a powerful actor tries to push a change to the protocol (such as changing the token issuance) and is supported by a majority of miners, if no one else Validate the blockchain, then this attack is easy to succeed because everyone's clients accept the new chain by default, and when people see what's going on, dissidents try to coordinate the rejection that chain. However, if ordinary users are verifying, then the coordination problem falls on the other side: those who try to change the agreement will be responsible for convincing users to actively download software patches to accept the agreement.

If enough users are validating, unnecessary confusion and disputes over forced changes to the protocol will be avoided. Chaos can cause a lot of damage, and it requires out-of-band social coordination to solve it. No motivation to attack. If the majority of users are validating (directly or indirectly) and the attack is only supported by the majority of miners, the attack will completely default to failure, which is the best of all outcomes.

secondary title

Defining Viewpoints vs. Coordinating Viewpoints

The image below is an example of Gavin Andresen's "by definition" view:bitcoinAnother perspective, from the Wasabi Wallet, is more straightforward from the point of view of explaining why full nodes are valuable:

Note that this view has two core parts:

1. By definition, the version of the chain that does not accept what you consider to be the fundamental and non-transferable rule is not

bitcoin

(or Ethereum or any other blockchain), no matter how many others accept the chain.

2. The important thing is that you must keep the rules on the chain that you think are acceptable.

However, I believe this "individualistic" view is very wrong. To see why, let's look at the situation we fear: the vast majority of participants may accept some change to the rules of the protocol that you consider unacceptable. As an example, imagine we have a future where transaction fees are low, and almost everyone else agrees to change to a new set of rules that increase issuance in order to keep the blockchain secure, but you stubbornly keep running A node that continues to enforce the old rules and forks to a different chain than the majority of nodes.

From your own perspective, you can still put tokens in a system that operates under the old rules that are acceptable. But so what? Other users won't accept your tokens at all, and exchanges won't accept your tokens either. The price website will list the price of the token, but their data source will definitely point to the token on the majority chain, so your token will be worthless. Cryptocurrencies and blockchains are fundamentally a social construct, and they mean nothing if no one else believes in them.

So what is the alternative view? A core idea presented here is to view blockchain as engineering security through the coordination problem.

Usually, most of the coordination problems we have in our world are bad things, here are a few examples:

2. Some people think that the United States may be better off if it switches to the metric system;

3. Others feel that if a 10% reduction in all prices and wages immediately in the event of a recession would help the country through, then doing so would require everyone to agree and is usually very difficult to achieve.

However, in blockchain applications, we use coordination problems to our advantage and the friction created by coordination problems to resist the malfeasance of centralized enforcers. As another example, we can build a system with property X, and we can guarantee that the system always retains property X, but changing the rules from X to not-X requires a bunch of people to agree to update their software at the same time. Even with an enforcer forcing the change, it would be very difficult - far more difficult than if a user were responsible for coordinating dissenters to resist the change.

Note that this point of view has a special consequence: the core purpose of your full node is not just to protect you, and in the event of a contentious hard fork, people with full nodes are safer than those without full nodes. Humans are vulnerable. On the contrary, the point of view here is more of a point of view of group immunity, that is: the more people who verify, the higher the security everyone has. Even if only some people are verifying, the result will make everyone Individuals are afforded a higher degree of protection.

secondary title

Now, we move on to the next topic, which is very relevant to topics like light clients and sharding: with validation, what will we accomplish? To understand this, let's go back to an earlier time - if an attack occurs on the blockchain, the way the attack occurs may have the following order of precedence:

default to failure > default to chaos > default to victory

The ">" here means "better than". At best the attack fails completely; at second best the attack causes chaos and everyone disagrees on the correct chain, and at worst the attack succeeds. The question here is: why is chaos so much better than victory? In fact, this is a matter of motivation, namely: confusion increases the attacker's cost, which means that the probability that the attacker will definitely win is greatly reduced, so the attacker is not encouraged to attack in the first place. A chaotic environment by default means that the attacker not only needs to win the blockchain war to 51% attack, but also convince the community to follow this "social war", which is much more difficult than just launching a 51% attack and winning by pure attack Much, much less attractive.

The goal of validation is to go from the default state from victory to chaos (ideally) and from chaos to failure (less ideal). If you have a fully validating node, and the attacker tries to push a chain with different rules, the attack will fail. If some people have fully validating nodes and many others do not, the attack can lead to chaos. However, now we must think of another question, namely: Is there any other way to achieve the same effect?

secondary title

Light Clients and Fraud Proofs

A natural development in this direction is light clients with fraud proofs. Most blockchain light clients currently on the market work by simply verifying that a majority of miners support a particular block, without bothering to check that other protocol rules are enforced. That is, the client operates on the trust assumption that most miners are honest. In the event of a contentious fork, clients follow the majority chain by default, leaving it up to users themselves to take aggressive steps if they wish to follow the old rules. Thus, light clients under attack today win by default. But with fraud prevention technology, things are starting to look very different.

As shown in the diagram above, individual blocks in the blockchain refer to only a few accounts. Fraud proofs will contain the data in these accounts along with a Merkle proof that this data is correct.

Fragmentation

This technique is sometimes referred to as stateless verification: clients can keep only the block headers instead of the full blockchain state database, and can verify any block in real time by asking other nodes for a Merkle proof of any desired state, In addition, the entries of the block verification can also be accessed.

The power of this technique is that light clients only validate standalone blocks when they hear an alert (and alerts are verifiable, so if light clients hear false alerts, then they can just stop listening alerts for that node). So under normal circumstances light clients are still light clients, they just check which blocks are supported by the majority of miners/validators. However, under special circumstances, such as when the majority chain contains a light client that will not accept the block, as long as there is an honest node to verify the fraudulent block, then the node will find that the block is invalid, as long as this A node broadcasts a fraud proof, and other nodes in the network reject it.

secondary title

Fragmentation

Sharding can be seen as a natural extension of network verification: in a sharded system, there are too many transactions in the system for most to sustain direct verification, but if the system is well designed, any invalid one can be detected Individual blocks, and this invalidity will often carry evidence of a fraudulent proof that can be propagated throughout the network. We can think of a shared network as if everyone is a light client, and as long as each shard has a certain minimum threshold number of participants, the network has herd immunity.

This is what auditability usually means in the real world: not everyone is verifying everything all the time, but:

(i) each particular part has enough eyes that if there is an error it will be found;

(ii) When an error is detected, it is ensured that it is clearly visible to all.

That said, blockchain can certainly improve this in the long run. One particular source of improvement is ZK-SNARKs (or "proofs of validity"): cryptographic proofs of valid verification that allow block producers to prove to clients that a block has satisfied some arbitrarily complex validity condition. Validity proofs are stronger than fraud proofs because they do not rely on interactive games to catch fraud. Another important technique is data availability checks, which prevent blocks from executing data that has not been fully published. However, data availability checks are based on the very conservative assumption that there are at least a small number of honest nodes somewhere in the network, and the good news is that there will always be honest nodes in the network, even in the presence of a large number of attackers.

secondary title