List of articles


brief introduction

In bitcoin P2P How to reach a consensus on the Internet ? What kind of transaction verification is needed to reach a consensus ? How do transactions and blocks spread to the entire blockchain network ? After reading this article, you will understand .

The consensus in bitcoin

Before I talked about distributed systems, I talked about several consensus algorithms of distributed systems , Include raft,Paxos And Byzantine fault-tolerant algorithms .

The consensus on bitcoin is different from what I said before , It uses workload proof (POW) The algorithm of .

Bitcoin's decentralized consensus is shared by all network nodes 4 Species independent processes interact to produce :

▷ Each full node independently verifies each transaction according to the comprehensive standard

▷ Through the completion of the workload to prove the algorithm check , Mining nodes package transactions into new blocks independently

▷ Each node independently checks the new block and assembles it into the blockchain

▷ Each node selects the blockchain independently , Select the blockchain with the largest cumulative workload under the workload proof mechanism

Verification of transactions

In the bitcoin network , Transactions are independently verified by the nodes in the network .

Before the transaction passes to the next node , Each bitcoin node that receives a transaction will verify the transaction first , This will ensure that only valid transactions spread across the network , Invalid transactions will be abandoned at the first node .

Each node checks every transaction , It's a long list of standards :

▷ The syntax and data structure of the transaction must be correct .

▷ Input and output list cannot be empty .

▷ The byte size of the transaction is less than MAX_BLOCK_SIZE Of .

▷ Every output value , And the total amount , It must be within the specified value range ( Less than 2,100 Ten thousand dollars , Greater than 0).

▷ No hash equals 0,N be equal to -1 The input of (coinbase Transactions should not be relayed ).

▷nLockTime It's less than or equal to INT_MAX Of .

▷ The byte size of the transaction is greater than or equal to 100 Of .

▷ The number of signatures in the transaction should be less than the maximum number of signature operations .

▷ Unlock script (scriptSig) You can only push numbers onto the stack , And lock the script (scriptPubkey) Must conform to isStandard The format of ( This format will reject non-standard transactions ).

▷ A matching transaction in the pool or in the primary branch block must exist .

▷ For each input , If the output of the reference exists in any transaction in the pool , The deal will be rejected .

▷ For each input , Look for referenced output transactions in the main branch and the trading pool . If the output transaction is missing any input , The deal will be an isolated deal . If the matching transaction has not yet appeared in the pool , Then it will be added to the isolated trading pool .

▷ For each input , If the referenced output transaction is a coinbase Output , The input must obtain at least COINBASE_MATURITY (100) Confirmations .

▷ For each input , The output of a reference must exist , And not spent .

▷ Use the referenced output transaction to get the input value , And check whether each input value and total value are within the specified value range ( Less than 2100 Ten thousand dollars , Greater than 0).

▷ If the sum of the input values is less than the sum of the output values , The deal will be suspended .

▷ If the transaction cost is too low to enter an empty block , The deal will be rejected .

▷ Each input unlock script must be verified against the corresponding output lock script .

After such a long check , The transaction is ready to be written to the block .

Building blocks

After verifying the transaction , Bitcoin nodes add these transactions to their own memory pool . A memory pool is also called a transaction pool , Used to hold transactions that have not been added to a block . Like other nodes , Mining nodes collect 、 Validate and relay new transactions . And unlike other nodes , The mining node will integrate these transactions into a candidate block .

The bitcoin node needs to assign a priority to each transaction in the memory pool , And select higher priority transaction records to build candidate blocks . The priority of a transaction is what is spent by the transaction input UTXO Of “ Block age ” decision , High transaction input value 、“ Block age ” Big deals are better than new ones 、 Transactions with small input values have a higher priority . If there is enough space in the block , High priority transactions will not cost miners .

then , The mining node selects the transactions that contain the minimum miner's fee , And in accordance with the “ Miners per kilobyte ” Sort , Preferring high miners' deals to fill the remaining blocks , The maximum block size is MAX_BLOCK_SIZE.

If there is still space left in the block , The mining node can select those transactions without miner's fee . Some miners will try their best to integrate those transactions without miners' fees into the block , Other miners may choose to ignore these deals .

After the block is filled , The remaining transactions in the memory pool become candidate transactions for the next block . Because these transactions remain in the memory pool , So as new blocks are added to the chain , These transactions are entered with reference to UTXO The depth of the ( Trade “ Block age ”) It's going to get bigger . Because the priority value of the transaction depends on the input of the transaction “ Block age ”, So the priority value of the deal increases with it . Last , A zero miner's fee The priority value of the transaction may meet the threshold of high priority , Packed into blocks for free .

Block verification

After the transaction is packaged in the block , This block will be broadcast out , The node receiving the block will check the block .

When a node receives a new block , It will validate the block against a long list of standards , If it doesn't pass the verification , This block will be rejected .

These standards can be found in the bitcoin core client CheckBlock Functions and CheckBlockHead Get in function , It includes :

▷ The data structure of a block is syntactically valid

▷ The hash value of the block header is less than the target difficulty ( Confirm that there is sufficient proof of workload )

▷ The block timestamp is two hours ahead of the validation time ( Allow time errors )

▷ The block size is within the length limit

▷ The first deal ( And only the first one ) yes coinbase transaction

▷ Use checklists to validate transactions within blocks and ensure their validity

The fork of the blockchain

Because blockchain is a decentralized data structure , So different copies can't always be consistent . Blocks may arrive at different nodes at different times , As a result, nodes have different blockchain perspectives . The solution is , Each node always selects and tries to extend the blockchain that represents the accumulated maximum workload , It's the longest or most cumulative difficulty chain .

In the first picture , The network has a unified blockchain perspective , With blue block as the main chain “ The vertices ”

When two candidate blocks want to extend the longest blockchain at the same time , Bifurcation events happen . Under normal circumstances , The bifurcation occurred in two miners in a short period of time , Each of them can calculate the workload to prove the solution .

Two miners found a solution in their respective candidate block 1 , And immediately spread your own “ win victory ” Block into the network , First, it propagates to neighboring nodes and then to the whole network .

Each node that receives a valid block will merge it into and extend the blockchain . If the node then receives another candidate block , And this block has the same parent block , Then the node will connect the block to the candidate chain .

As a result, , A node has received some blocks , Other nodes receive another candidate block , At this time, two different versions of blockchain appear .

If you work in “ green ” The miners in the block found one “ Pink ” Blocks extend the blockchain ( Blue - green - Pink ), They're going to spread this new area right away , The whole network will think that this block is valid .

All in the last round of selection “ green ” The winner node will directly extend the chain by a block .

However , Those choices “ Red ” The node whose block is the winner will now see two chains :“ Blue - green - Pink ” and “ Blue - Red ”.

As shown in the figure , These nodes will, based on the result, change “ Blue - green - Pink ” This chain is set as the main chain , take “ Blue - Red ” This chain is set up as a spare chain . These nodes accept new, longer chains , Forced to change the original view of blockchain , This is called a new consensus of the chain .

because “ red ” As the parent block, the block is no longer on the longest chain , So their candidate block has become “ Solitary block ”, So now anything that would have wanted to be in “ Blue - Red ” The miners who extend the blockchain on the chain will stop .

The whole network will “ Blue - green - Pink ” This chain is identified as the main chain ,“ Pink ” The block is the last block in the chain . All miners immediately switch the parent block of their candidate block to “ Pink ”, To extend “ Blue - green - Pink ” This chain .

Types of blockchain forks

Generally speaking, there are two kinds of bifurcations of blockchain :

Hard branch , It's when the rules of bitcoin protocol change , The old node refuses to accept the block created by the new node . Blocks that violate the rules will be ignored , Miners will follow their rule set , Create blocks after the blocks they last witnessed .

Soft branch , It's when the rules of bitcoin protocol change , Old nodes don't realize that the rules are different , They will follow the changed rule set , Continue to accept blocks created by new nodes . The miners may not understand at all , Or work on a verified block .

Through hard forks , Blockchain is not the original blockchain .

You can see from the above picture that , Bitcoin has evolved a lot from its original version , They are all the same in nature , The question is which chain do you approve of .

summary

This paper introduces the consensus mechanism of blockchain , And transaction verification steps , Finally, it explains the bifurcation of blockchain . I hope you like it .

The author of this article :flydean Program those things

Link to this article :http://www.flydean.com/bitcoin-consensus/

In this paper, the source :flydean The blog of

Welcome to my official account. : Program those things , More wonderful waiting for you !