Now let’s look at the consensus protocol in Bitcoin. One of the problems that consensus in Bitcoin has to solve is that some nodes may be malicious. Let’s assume that most of the nodes in the system are good and the ones with malicious intent are a small percentage, so how do you go about designing a consensus protocol in this case. One idea is, since most of the nodes in the system are good, can we just vote? For example, a certain node, it puts forward a candidate block, it picks which transactions are legitimate based on the transaction information it receives, and then packs these transactions into a block in a certain order, and then it releases this candidate block to all the nodes. After the other nodes receive the block, they check whether all the transactions in it are legal, if they are all legal, they will vote for it, if there is a transaction that is illegal, they will vote against it, and finally count the votes, if more than half of them are in favor of it, then the block will be formally accepted, and it will be written into the block chain, which is a voting scheme. Is it feasible? If it is not feasible, that is to say that everyone has to participate in this calculation, then if the malicious nodes have been continuously attacked, continuously send out the wrong, as a result, everyone will not stop voting, so that time is wasted on the vote, the blockchain can not be developed down the road. There is also a problem of efficiency, because we have to vote, but the network delay situation, can not be determined in advance, how long to wait for each round of voting, there will be a problem of efficiency.
These are actually some of the details of the problem, there is a bigger problem is that the voting-based scheme, first of all, to determine who has the right to vote, there is a MEMBERSHIP problem. If the membership of the blockchain is strictly defined, for example, a certain blockchain is not open to anyone, only certain qualified people can join, in this case the voting-based scheme is feasible. But that’s not the case in the Bitcoin system. It’s very easy to create an account in the Bitcoin system. You generate a public-private key pair locally and that’s an account, and it doesn’t need to be approved by anyone, and in fact no one else knows that you’ve generated an account. After you generate a public-private key pair locally, how does anyone know about it? They won’t know until you transfer money. If you just generate a public-private key pair, you do not do anything, others do not know, only when you have a transaction with the outside, others will know that the existence of your account.
A malicious node can generate a large number of accounts through a supercomputer, generating more than half of the total number of accounts, you can gain control and thus manipulate the results of the vote, this is called a Witch Attack.
Voting doesn’t work, so what do we do? The Bitcoin system uses a very clever mechanism to solve this problem. It’s also voting, but instead of voting by number of accounts, it’s voting by computational power. Each node can locally assemble a candidate block, put what it thinks are legitimate transactions into that block, and then try various nonce values.
BlockHeader has a field that is a random number nonce, after assembling the block, it starts to try various random numbers, which are 4 bytes, to see which random number can satisfy the inequality H(block header) <= target, and the resulting hash falls within the specified range. If a node finds a nonce that meets the requirements, we recognize it as having bookkeeping rights, which is the right to write the next block into the decentralized Bitcoin ledger. Only the node that finds the nonce that has been granted bookkeeping rights has the right to post the next block. So when other nodes receive the block, they have to verify the legitimacy of the block.
First of all, you need to verify that the block header is filled out correctly, like there is a field in the block header, the nBits field, which is actually an encoding of the value of the target field, so you need to check if the nBits field is set up in accordance with the difficulty requirements stipulated in the Bitcoin protocol. Check to see if the nBits field is set to meet the difficulty requirements of the Bitcoin protocol.
And then check that the nonce, if the nonce is selected, is the hash of the entire block header less than or equal to the target field value. In other words, you want to publish a block, do you actually have the right to publish the block, do you actually get the right to bookkeeping? Just check all those items in the block header, if they all meet the requirements, and then look at the list of transactions inside the block body and verify that each transaction is legitimate. The first must have a legitimate signature, and the second has not been spent before. If any of them don’t meet the requirements, then the block can’t be received and will be discarded.
Suppose there is a block that has been checked for compliance with all the requirements, then is it acceptable?
Is it possible that a block has been checked, the block header is compliant, and all the transaction lists are compliant, but there are a few possibilities that we might still be reluctant to accept. What are the possibilities? The block is inserted somewhere in the middle of the blockchain, it’s not at the end, it’s in the middle. After receiving a block, how do you know where it is inserted? It is through the hash of previous block header, that is, according to the pointer of the previous block to know which position it is inserted.
What’s the problem with inserting it in the center? When verifying whether it is double spending, from the current block to the source of the coin, these intermediate blocks have not spent the coin. If the blocks in between have not been spent, then the transaction is legitimate. And verifying whether a transaction on one fork is legitimate or not doesn’t look at transactions on another fork. This leads to a situation where a block is not on the longest valid chain, even though all the transactions in that block are legitimate.
This is an example of how the Bitcoin protocol states that accepted blocks should be on the extended longest valid chain. A block should be attached to the back of the longest valid chain in order to be a legal block. The example above is actually an example of a fork attack, called a forking attack, which rolls back a transaction that has already occurred by inserting a block into the middle of the blockchain.
Forks can also occur under normal circumstances. If two nodes get bookkeeping rights at the same time, how do they get them? Each node assembles a block locally as it sees fit, and then tries out a variety of nonces, and if both nodes find one that matches the requirements at about the same time, then they can both post the block. This will result in two equal-length forks, both of which are the longest legal ones if they are both legal according to the longest legal chain principle. So which one should be accepted?
Among the Bitcoin protocol, by default, each node is accepting the one it received earliest. So, depending on where they are in the network, some nodes may hear this block first and accept it, and some nodes may hear another block first and accept it.
The Bitcoin protocol is that if you continue to expand along this block of yours down the line, it’s considered to be an endorsement of this block that you posted.
For example, if he receives your block and then expands a new block down the line, it shows that he is recognizing this block of yours, and if he doesn’t expand this block of yours, he is not recognizing this block of yours. So if there’s a situation in the Bitcoin system where two nodes release blocks at about the same time, then this equal-length temporary fork will remain for a while until one of the forks finally wins. So when there’s a temporary fork, it’s really a competition for arithmetic and of course some competition for luck to see which one of the forked blocks grows faster, and one of them will become the longest legal chain and turn out to be the one that everybody accepts.
Why should everyone compete for this bookkeeping right? First of all, the node that gets the bookkeeping right itself has certain rights, it can decide which transactions are written to the next block. But the protocol should not be designed in such a way that this becomes the main driver of the competition for bookkeeping rights. If this becomes the main motivation there is a problem, because we are hoping that all legitimate transactions should be able to be written to the blockchain.
So what to do? There’s a very smart mechanism in Bitcoin designed to solve this problem. It’s called a block reward, which is a provision in the Bitcoin protocol that says that the node that gets the right to keep track of the book can have a special transaction in the block that it posts, which is the minting transaction that we talked about earlier. In this transaction, a certain number of bitcoins can be released.
As mentioned earlier, a decentralized digital currency has to solve two problems, the first one is who has the right to issue the currency and the second one is how to verify the legitimacy of the transaction? This section has been all about the second question so far, how do you verify the legitimacy of a transaction?
Now let’s go back to the first question, who decides to issue the currency. This coinbase transaction is the only way to issue new bitcoins in the bitcoin system, and all other transactions are nothing more than transferring existing bitcoins from one account to another, including the fiat currency that we sometimes use to buy bitcoins, this minting of– The coinbase transaction is the only way to generate new bitcoins. The coinbase transaction doesn’t have to specify the origin of the coins, because the coins are created out of thin air. How many coins can be created? In the beginning, when Bitcoin first went live, 50 Bitcoins could be generated for each block that was released. This BTC is the symbol for Bitcoin.
Different cryptocurrencies have their own symbols, and BTC is the symbol for Bitcoin. In the beginning, the outgoing block reward for Bitcoin was 50 Bitcoins, but the protocol states that after 210,000 blocks this outgoing block reward is halved and it becomes 25. Bitcoin starts with 210,000 blocks, and each block can have 50 bitcoins issued in it when it’s released, and then only 25 bitcoins can be issued in each block after that. After another 210,000 blocks, it’s halved again to 12.5 bitcoins. Now only how many bitcoins can be released in each block? It looks like it’s decreasing very quickly, and it’s much more competitive now than it was before.
If there’s a fork, and one of the forks wins, is the outgoing block reward from the coinbase transaction in the block of the remaining fork useless? Basically yes. It means that if there’s a very long block that becomes the longest legal chain, and the fork remembers how many bitcoins are in it, but the validation of the transaction is to verify that the block is in the right fork, and the Bitcoin protocol requires that it accepts the longest legal chain, so if the transaction is connected to a very short fork, it’s not going to be useful to get bitcoins on that fork because most honest nodes won’t accept it.
What exactly is the consensus that Bitcoin, the consensus mechanism, is trying to achieve? The previous example, which was talking about distributed hash tables, had a system with many servers that work together to maintain a distributed hash table. What is the consensus to be achieved? It’s what’s in the hash table, what are the key-value pairs, and that’s the consensus that’s going to be achieved.
The consensus that’s going to be achieved in the bitcoin system is what’s in this decentralized ledger, and that’s the consensus that’s going to be achieved. So who gets to decide what’s in this ledger? Only nodes that have been granted bookkeeping rights can write into it. So how to get the bookkeeping rights? You have to solve the puzzle H(block header) <= target. Why do you say that Bitcoin’s consensus mechanism relies on the power of the algorithm to vote?
It’s because of the puzzle friendly property mentioned in the previous section. This property ensures that there are no shortcuts to solving puzzles, and that you can only try them out one by one, so if a node has ten times more power than another node, the probability that it will get the right to write the book is also ten times higher than the probability of that node. Voting by math power, that’s what’s special about voting in bitcoin, it’s not one person one vote, it’s not one computer one vote, it’s the number of nonces you can try per second. This is sometimes called the hash rate, and this determines the weight of the vote. The higher the hash rate of a node, the higher the probability that it will be rewarded with a block.
How can this method prevent the witch attack problem mentioned earlier?
Because the vote is to rely on computing power to vote, create how many accounts actually has no effect, you can create 1 account on top of your server, 100 accounts, or create 10,000 accounts, but does not make your hash rate increase, does not make you try to increase the number of nonce per second, so the weight of the vote does not change.