V God: When we verify the blockchain, what are we doing?
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from
Ethereum enthusiasts (ID: ethfans)
, Author: Vitalik, translation & proofreading: Elisa & A Jian, reprinted by Odaily with authorization.
But in practice, how many validators do we really need? A hundred independently validating nodes? a thousand? Do we need to have every normal person in the world running software to check all transactions? Answering these questions is our challenge, especially if we want to build a blockchain with a consensus mechanism that is more advantageous than a single-chain Nakamoto proof-of-work. Solving these questions is particularly important.
secondary title
why verify
image description
There are two main benefits of users validating the blockchain. First of all, this can allow nodes to participate in the process of determining the legal chain (that is, the chain that is accepted by the entire community and has legitimacy) to the greatest extent. Generally speaking, a legal chain is defined as "the valid blockchain supported by the most miners or validators", such as the "longest valid chain" in Bitcoin. Invalid chains are by definition rejected, and if multiple valid chains compete, the chain with the most miner or validator support wins. So if you run a node that verifies the validity of all blocks, you will be able to detect which chains are valid and which are not, which will maximize your chances of detecting legitimate chains.
But there is actually a deeper benefit to users validating the blockchain. If a powerful actor attempts to get the network to accept a change to the protocol (such as changing the issuance), and there is a majority of miners in favor of it, the attack is easily accomplished without anyone else validating the blockchain . And, all clients will accept this new chain by default. When everyone comes to their senses and realizes this, they can only rely on opponents to reject this new chain through coordination. But if ordinary users also participate in verification, then the situation is completely different, and attackers who attempt to change the protocol need to persuade verified users to actively download their software patches to change the protocol.
If enough users participate in validation, when someone tries to make a controversial change to the protocol, the default will not be success, but confusion. Natural chaos will also cause damage to the network, which requires social coordination outside the protocol level to solve, but it also places a greater obstacle in front of the attackers, making them unable to be confident that they can succeed in one blow and then walk away. Greatly reduces their willingness to attack. If a majority of users participate in direct or indirect verification, and the attacker only has the support of a majority of miners, then the attack will naturally fail, which is the best outcome for everyone.
secondary title
Defined Perspective vs Collaborative Perspective
It should be noted that the logic of the above reasoning is very different from another kind of reasoning we often hear: they say that as long as the chain changes the rules of the protocol, it will not be a legal chain "by definition", and the important The problem is not how many users are willing to receive the new set of rules, but that you can always stay on the chain using the old rules you like.
Take a look at this example from Gavin Andresen discussing the matter from a "definition perspective":
"Bitcoin" is a transaction ledger that records, in the form of a blockchain, legally signed transactions that spend previously unspent funds. The chain begins with the genesis block, whose hash is 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, which issues 21 million bitcoins on the chain that has accumulated the most double-SHA256 proof-of-work on a predetermined schedule.
Another definition from the Wasabi wallet, which is more straightforward to explain the value of a full node:
When running a Bitcoin full node, you can define the exact currency rules you agree with. No one can force that on you. Therefore, any autonomous entity pursuing financial freedom should run a full node. After determining its own rules, the full-node software can find nodes that meet our rules in the Bitcoin peer-to-peer network. These nodes send us transactions that they judge to be valid according to their rules, and we verify them according to our own rules. If we receive a transaction that does not meet the rules, we can mark it as an invalid transaction and disconnect from the source node of the invalid transaction.
secondary title
Assert your monetary sovereignty
Using a full node gives us the power to define, validate and enforce the rules of our Bitcoin currency.
We should pay attention to the two cores in the perspective of "definition":
The most important thing is that you stick to the chain that conforms to your own rules.
From your point of view, you do still have the currency in the system built on the basis of the rules you agree with, but so what? Nobody else accepts your currency anymore. The exchange won't accept it, the website may show a skyrocketing price for the new currency, but it's the currency on the chain with the majority of users, and your currency will become worthless. Cryptocurrencies and blockchains are fundamentally social constructs. They are meaningless if no one else believes in them.
So from what angle should we look at this issue? Central to this perspective is the blockchain as an example of exploiting coordination problems to achieve security.
In general, real-world reconciliation problems are hard: although for most people it would be better if English changed its highly complex and irregular spelling system to phonetic spelling; although it would be better if the United States switched to metric Good; while in a recession it would be better if we cut all prices and wages together by 10% at once, in practice this would require everyone to agree to these shifts at the same time, which would be very difficult to achieve.
But in the application of blockchain, the coordination problem has become our advantage. We exploit the friction caused by coordination problems to prevent malfeasance by core players. We can build systems that have property X and guarantee that property X will be preserved, because changing a rule from property X to non-X requires a bunch of people to agree and update their software at the same time. Even if a single actor could force a change, it would be much harder for him to do so than it would be for opponents to actively coordinate resistance to change.
text
We should pay attention to the special consequences of holding this point of view: the purpose of running a full node is not only to protect its own interests. In the event of a contentious hard fork, users who run a full node are safe, but not without a full node. To a greater extent, this can be seen as a kind of herd immunity. The more people who verify, the safer everyone is, and even if only some people verify, everyone can obtain a higher degree of protection.
secondary title
An in-depth discussion of "validation"
Default causes failure > Default causes confusion > Default succeeds
The "greater than sign" here means that the former is better than the latter. The best case is that the attack fails directly, the sub-optimal case is that the attack leads to confusion, and everyone cannot agree on the legal chain, and the worst case is that the attack succeeds. Why is it so much better to create chaos than to succeed in an attack? It comes down to incentives, confusion also imposes a cost on the attacker, making them less confident that the attack will be successful, thus reducing the incentive for the attacker to launch an attack. The environment that naturally leads to chaos means for attackers that they need to win the blockchain war (successfully launch a 51% attack) and win the "public opinion war" to convince the entire community to follow the attack chain. This makes an attack far more difficult and less profitable than simply launching a 51% attack is guaranteed to succeed.
The goal of verification is to take an attack from a state where it naturally succeeds, to a state where it naturally fails (optimal), or to a state where it naturally leads to confusion (suboptimal). If you run a node that fully validates all blocks, and the attacker tries to get the network to accept a chain with different rules, the attack will fail. If some users run validating full nodes and many don't, the attack can lead to chaos. But we still have to think, is there any other way to achieve the same effect?
Light Clients and Fraud Proofs
A better approach is naturally to use a light client with fraud proofs. Most current blockchain light clients only verify that a majority of miners support a particular block, not that protocol rules are satisfied. The normal operation of these clients assumes that the majority of miners are honest. Once a controversial fork occurs, such clients will naturally follow the trend, and users need to take proactive measures to stay on the minority chain under the old rules. Therefore, for the current light client to launch an attack, the attacker can naturally succeed. But with fraud proof technology, the situation is quite different.
In simple terms, fraud proofs work as follows. Generally speaking, a single block in the blockchain will only refer to a small part of the "state" of the blockchain (account balances, smart contract code...). If a full node processes a block and finds that it is invalid, it can generate a data packet (that is, a fraud proof) and broadcast it to the light client. The data packet only includes the block and enough data to process the block. After receiving the data packet, the light client can verify the block by itself without requiring other data on the chain.
This technique is sometimes called stateless verification. Clients can record only the block headers without recording the complete blockchain state data, and can verify in real time by requesting Merkle proofs of arbitrary state entries from other nodes. block.
Fragmentation
The power of this technique is that light clients will only verify a single block after receiving an alert (the alert is also verifiable, if the light client finds a false alert, they can stop listening to the node's alert), so Under normal circumstances, light clients remain lightweight and only check which blocks are supported by a majority of miners or validators. However, in special cases, if the chain where the majority of people are located contains a block that the light client does not accept, as long as at least one honest full node verifies the problematic block, it can be known that it is invalid and broadcast Fraud proofs such that other nodes in the network also reject it.
secondary title
Fragmentation
In addition, another point is very important: in the sharding system, the threshold for block generation (not just verification) is very low, and it can even be done on a home laptop. The core of the network does not rely on high-performance hardware, which ensures that the threshold for the opposition to be a minority is low enough, which makes it more difficult for the majority-dominated protocol to be turned into a "natural attack success" state by the attacker (forcing others to obey on its attack).
This is also the meaning of auditing in the real world: not everyone is verifying everything at all times, but first, there are enough people checking each particular part, and any errors are guaranteed to be found, and second, once Errors are checked, and everyone can clearly see where they went wrong.
Having said that, in the long run, the blockchain can definitely go further in this regard. One source of progress is ZK-SNARKs (or "validity proofs"), an efficient and verifiable cryptographic proof that enables block producers to prove to clients that blocks satisfy some arbitrarily complex validity condition. Validity proofs are stronger than fraud proofs because they do not rely on interactive games to catch deception. Another important technique is "data availability checks", which can detect blocks that do not have full disclosure content. Proofs of data availability do rely on some security assumptions, but this assumption is very conservative: there is still a small number of available nodes in the network that are honest ("willing to abide by the agreement"); the good news is that this minimum number of honest validators is low, and Even if the number of attackers is very large, there is little need to raise the requirement.
secondary title
Now, let's look at the most powerful consequence of the "natural chaos" pattern: the 51% attack starts attacking itself. In many current communities, if a 51% attack occurs and the attacker wins, then the 51% attack chain becomes a legitimate chain. This specification is strictly followed by everyone. The recent 51% attack on Ethereum Classic illustrates this point. The attacker rolled back more than 3,000 blocks, stealing 807,260 ETC with a double spend attack in the process. Since one of the two classic clients of Ethereum (OpenEthereun) is technically unable to return to the historical height of the attack chain, Geth nodes can run on the attack chain, while OpenEthereum can only be trapped on the original chain.
We can say that the attack did lead to chaos, but it was an accident rather than an intentional design by the Ethereum Classic community. It is a pity that the community subsequently chose to accept the (longer) attack chain as legitimate. The Ethereum Classic twitter account called it "a strict adherence to proof-of-work like our original intention". Therefore, this community norm actively helps attackers win.
But in fact, we can reach another consensus on the definition of a legal chain. For example, establish a rule that after a block has more than 100 descendant blocks, its legitimacy cannot be subverted. Or, a proof-of-stake with finality (such as Ethereum 2.0 is the case), the rule is that once a block is finalized, it will never be rolled back.
image description
This approach also has the potential to grow. We could try to create a 51% attack to specifically censor transactions that would cause confusion. Research on timeliness verifiers is also driving all types of attacks toward natural failure. Even so, there will still be some confusion, because the timeliness validator can't help those nodes that are offline or have a bad network connection.
in conclusion
For the blockchain community that values immutability, it can be said that this measure of restricting rollback is a good choice, if no matter how long ago the network accepted a transaction, it may still be rolled back accidentally , then the blockchain cannot claim to be immutable. Of course, I believe that even BTC and ETC have limited rollbacks in extreme cases. If an attack tries to roll back weeks of block history, the community can initiate a soft fork that requires active user participation to deny the attack the chain of recipients. But more explicit agreement and formalization of this measure would go a step further.
secondary title
in conclusion
So what does this story teach us? First, if we accept the legitimacy of social collaboration, and the legitimacy of indirect verification assuming a "1-of-N" trust model, that is, assuming that there is always an honest participant in the network, rather than assuming A certain participant (such as Infura) is always honest, then we can create a more scalable blockchain.
