1. The difference between digital currency and paper currency
If the central bank wants to issue digital currency, if you directly sign the currency’s denomination and other information with the central bank’s private key, and then use it, the user directly verifies the signature with the central bank’s public key, so it will not work, because you can use this Digital currency is used to buy things again, which is called double spending attack. The signature ensures that the denomination and other information cannot be modified, but this digital file can be copied in many copies. If it is paper currency, you will lose it when you spend it. This is the difference between digital currency and paper currency.
Decentralized currency needs to solve two problems:
①Issuance of digital currency
② How to verify the validity of the transaction and prevent double spending attack.
2. Two solutions
Centralized solution:
It is not enough just to have a denomination. Each digital currency must also have a number. Regardless of decentralization, the central bank also maintains a database, which records which user owns each numbered digital currency.
When paying, not only must the public key be used to verify that the signature is signed by the central bank, but also the central bank must verify that the currency is owned by itself, and the central bank will then change the currency owner to the user who paid for it. Not only the issuance of digital currency is done by the central bank, but each transaction must be confirmed by the central bank to confirm its legitimacy. This solution is a centralized solution.
Decentralized solution:
Change the functions of the central bank to be shared by the majority of users, that is, a decentralized solution. This is a problem to be solved by digital currency systems such as Bitcoin, namely:
How to determine the issuance and volume of digital currency
How to verify the legitimacy of transactions and prevent double-spend attacks
The first problem is determined by mining in the Bitcoin system, which will be learned later.
The solution to the second problem is to maintain a data structure like the centralized solution, but it is no longer maintained by the central bank, but by all users. This data structure is no longer a relational table, but blockchain .
As shown in the figure below, assuming that user A has obtained the coinage right (the right to issue currency) , he issued 10 bitcoins, that is, he has obtained 10 bitcoins. Then he transfers the 10 bitcoins to B and C, each of whom shares 5 bitcoins. Next, B gives C 2 coins and D 3 coins. Finally, C gives all the 7 coins obtained to E.
Each transaction in the Bitcoin system is divided into an input part and an output part. The input part should give the source of the bitcoin of this transaction and the public key of the payer, and the output part should give the hash of the public key of the payee. value . The receiving address in the Bitcoin system is obtained by hashing the public key of the payee and then undergoing some transformations.
There are two kinds of hash pointers involved here, one is the cobalt blue one in the picture, which strings together the various blocks; the other is the dark red one in the picture, which is to illustrate which transaction the source of the coin comes from. of.
Here, "explaining the source of the currency" also prevents double-spending attacks. For example, in the figure below, B has already spent his 5 bitcoins. Suppose B tries to spend again and transfers 5 bitcoins to F. At this time, follow the block chain to check the blocks between this block and the source transaction, and find that B has already spent the bitcoins of the source block, indicating that this new transaction is illegal, and will not accept this block Blocks enter the blockchain.
Similar to the fact that banks do not provide the function of querying a user's bank account number, the Bitcoin system does not provide the function of querying a user's public key or account address. To transfer money to a user, the other party needs to provide the public key or account address. In this case, the payee can publish the public key on the website.
However, when A transfers money to B, in addition to A needing to know B's address, B also needs to know A's public key. Because on the one hand, the public key of A represents the identity of A, and B needs to know who is transferring money, and on the other hand, it is to verify the signature of A in the Bitcoin transaction (private key signature public key verification), that is to say, all nodes need Know A's public key.
Each node on the blockchain needs to be independently verified, even a bystander who has nothing to do with the transaction must verify the legitimacy of the transaction.
In this case, how does one know A's public key? Here, as we learned earlier, A’s public key is written by A himself in the input part of the transaction, which is declared by the payer in the transaction. But will this cause other people to pretend to be A to initiate transactions? For example, B's accomplice B' says that he is A, then signs with his private key, puts his public key that is A's public key in the transaction input part, and tries to transfer the bitcoin on A's account.
But because the output part of the transaction in the source of the coin (minting transaction in the figure) has the hash value of the public key of the payee A , at this time, the hash value of the public key forged by B' is matched with the hash value of the public key of A Not on, so this attack can be prevented.
If B' directly uses A's public key to write it, but because there is no A's private key, the signature cannot be verified with A's public key at this time, which is obviously not possible.
The input part and output part of the transaction are actually scripts, and A's public key is also written in the input script of this transaction. The verification process of the public key is actually to put together the input script of this transaction and the output script of the transaction of the source of the currency to see if it can be executed smoothly.
In the previous pictures, only one transaction is spent in each block. In the actual system, there can be many transactions in each block. These transactions form the Merkle Tree learned in the last lesson.
block structure
Here we supplement the structure of nodes in the blockchain learned in the previous section, and describe the block header and block body in detail.
What is connected in the above figure is the block header, the block body is hung on the block, and the hash pointer and the block body are not directly connected (the indirect connection is established through the root hash of the Merkle Tree).
Note that a fully validation node has a block body and needs to verify the legitimacy of all transactions; a light node has no block body and cannot independently verify the legitimacy of transactions.
Light nodes do not participate in the construction and maintenance of the blockchain, but only use part of the information in the blockchain.
Most of the nodes in the system are light nodes, and there are not many full nodes.
block header
The block header stores the macro information of the block.
- Which version of the Bitcoin protocol is used
- Hash pointer pointing to the block header of the previous block (Note! The hash value here only calculates the block header of the previous block, and the root hash of the Merkle Tree saved in the block header can already ensure that all transactions stored in the block have not been tampered with up)
- The root hash value of the entire Merkle Tree
- Mining difficulty target threshold target
- The random number nonce used for mining must make H ( blockheader) ≤ target
block body
-
transaction list
Mining solution problem: Hash (block header) <= target
Hash of previous block header only calculates the hash of the block header (Merkle root hash ensures that the content of the block body is not tampered with, so only the block header needs to be calculated to ensure that the entire Block content will not be tampered)
In the blockchain system, light nodes (only store block header information) only use the blockchain, but do not participate in the maintenance and construction of the blockchain system.
3. Consensus Agreement
Another problem is that each account can publish transactions, and the blockchain can be regarded as a ledger, so in which block should the published transactions be written? The transaction is broadcast to each block, and everyone writes the transaction on their own local blockchain. How to ensure the consistency after writing? That is to say, the content of the ledger must obtain a distributed consensus (distributed consensus) .
Some impossible conclusions of distributed systems
There are many impossible conclusions (impossibility result) in the research of distributed systems.
- FLP impossibility result
The FLP impossibility result talks about that in an asynchronous system (asynchronous system), there is no upper limit to the delay of network transmission, even if only one member is faulty, it is impossible to reach a consensus.
FLP is the initials of the names of three experts who study distributed systems.
- CAP Theorem
CAP is the three properties that a distributed system wants, Consistency, Availability, and Partition tolerance. And CAP Theorem means that in any distributed system, the three properties of CAP can only satisfy two of them at most, and it is impossible to satisfy all three.
A well-known protocol in distributed consensus is Paxos, which can guarantee consistency. That is, if the agreement reaches a consensus, the consensus must be consistent (that is, there will be no inconsistent consensus between two members of the system). However, the Paxos protocol has a small probability (although small but objective), which makes the system unable to reach a consensus.
The protocol Paxos in the distributed consensus can guarantee Consistency (if a consensus is reached, it must be consistent), but in some cases, it may not be possible to reach a consensus.
[A detailed explanation of the Paxos protocol is attached here: https://my.oschina.net/u/150175/blog/2992187 ]
4. Consensus Protocol in Bitcoin
Background: Assume that some nodes in the system are malicious, but the proportion is small. The majority of nodes are "good" nodes, in which case the consensus protocol is set.
Idea 1: Direct voting
A node packs the transaction into a block and sends it to other nodes. Other nodes check the candidate block and check if they voted for it correctly. If more than half of the votes are voted, they join the blockchain.
Existing problem 1 - Malicious nodes continue to package illegal blocks, resulting in the failure to reach a consensus, and all the time is spent on voting.
Existing problem 2 - there is no means of forced voting, and some nodes do not vote (administrative inaction).
Existing problem 3 - the network delay is unknown in advance, how long does it take to vote? There will be problems in efficiency.
A bigger problem - membership. If it is a joint uoyi s alliance chain, there are requirements for joining members, which can be based on voting. But in the Bitcoin system, anyone can join, and creating an account is extremely simple, and only needs to generate a public-private key pair locally. Only when transferring money (transaction), the Bitcoin system can know the existence of the account. In this way, hackers can use computers to specifically generate a large number of public-private key pairs, and when they generate a large number of public-private key pairs exceeding half of the system, they can gain dominance (Sybil attack). Therefore, this simple voting scheme is also not feasible.
A very ingenious solution is adopted in the Bitcoin system to solve this problem. Although it is still a vote, it is not simply based on the number of accounts, but on the basis of computing power.
In the Bitcoin system, each node can assemble a candidate block by itself, and then try various nonce values, which is mining. [H(block header)<=target]
When a node finds a nonce that meets the requirements, it obtains the right to bookkeeping, so that the block can be published to the system. After other nodes receive the block, they verify the validity of the block. If the majority of nodes in the system pass the verification, they receive the block as the latest block and add it to the blockchain.
1. Will legal blocks be rejected?
as the picture shows. In the case of a fork, the fork situation is temporarily saved, but the blockchain only recognizes the longest legal chain. As time goes by, there must be a certain chain that becomes the longest legal chain. In this way, it will also cause the legal block to be rejected
2. Fork attack
As shown in the figure, user A rolls back the above record of transferring money from A to B, thereby illegally obtaining benefits. On both chains, the discovery transaction is legal. This is a typical double spend attack. After A transfers money to B, use a fork attack to transfer the money back, overwriting the original record.
In the Bitcoin system, this situation is actually very difficult to happen. Because most miners recognize the longest legal chain, they will continue to dig along the above chain. And if the attacker A wants to roll back the record, he must make the lower chain longer than the upper chain. Theoretically, an attacker needs to reach 51% of the computing power of the entire system to make this attack successful.
In addition, in the normal operation of the blockchain, forks may also occur. When two nodes obtain bookkeeping rights at the same time, there will be two legal chains of equal length. By default, a node receives the block it hears first, and the node continues along that block. But as time goes on, there must be a chain that wins, thus ensuring the consistency of the blockchain. (Blocks that are thrown away are called "orphan blocks")
It can be seen that relying on computing power competition can effectively prevent "sybil attacks".
4. Bitcoin Incentive Mechanism
Why do nodes in the system compete for bookkeeping rights? Need to provide computing power and electricity cost, why do nodes do it?
This problem was taken into consideration at the beginning of the design of the Bitcoin system, that is, the introduction of an incentive mechanism. Bitcoin solves this problem by setting block rewards . A node that obtains a legal block can add a special transaction (minting transaction) to the block. In fact, this is the only way to generate new bitcoins.
The design of the Bitcoin system stipulates that at the beginning, 50 bitcoins can be obtained for each block, but every 210,000 blocks thereafter, the reward will be halved.
But is this all right? ? ?
Transaction records are saved in blocks, so, will there be nodes that only want to publish blocks but not pack transactions? When Satoshi Nakamoto designed the system, he introduced transaction fees. In a block, its input >= output, and the difference is the handling fee to the node to which the block belongs. These will be detailed in subsequent articles.
Five, some problems
What exactly is the consensus achieved by the consensus protocol?
In an ordinary distributed system, such as a distributed hash table, the consensus obtained is the content in the hash table. In the Bitcoin system, the consensus achieved by the consensus protocol is the transaction in the decentralized ledger.
Only nodes that have obtained bookkeeping rights can write transactions in blocks, and the way to obtain bookkeeping rights is to solve the inequality puzzle. According to the nature of the hash function puzzle friendly learned in the first lesson, the process of solving this puzzle is not The shortcut can only be tried one by one nonce, so it can be used as a proof of workload. The stronger the computing power, the greater the probability of getting a block reward, so it is said that voting is based on computing power in the Bitcoin system.
How does voting by computing power avoid sybil attacks?
Because voting is based on computing power, it doesn't matter how many accounts are created. Creating many accounts will not increase the number of nonce attempts per second.
Why describe the process of obtaining bookkeeping rights as mining?
The number of mines is limited, and the total amount of bitcoins is limited.
The process of mining is difficult, and the reward for mining is very high. The same is true for Bitcoin to obtain bookkeeping rights to obtain block rewards.