Interpreting blockchain, soft fork and hard fork
Recently in the Exchange Group and the forum often hear soft fork and hard fork, at first, this concept is simply considered to be a blockchain software upgrade after the old and new protocol caused by new and old nodes of the new block recognition of a disagreement, soft fork generally does not produce a permanent fork chain, and the hard fork will produce two chains, if most of the nodes are upgraded , the old chain survives to look at the size of the force.
The information is queried and the concept of soft and hard fork is clarified again.
The problem of soft and hard fork is to go to the central node software, protocol, version upgrade problem, all the nodes running in the blockchain have the same software, adhere to the same consensus mechanism, maintain the same chain, but once the software, protocol, version upgrade, all nodes can not be updated to the same version at the same time, This causes some nodes to have a new consensus protocol mechanism, when there will be new, old and two nodes in the network. Then in the Block generation, the new node generated chunks, the old node will be considered legal or illegal, the old node generated chunks, the new node will also be considered legal or illegal. There is always a 51% critical point in the blockchain, so we think the new node is more than 50% of the calculation force.
First, the soft and hard fork to do an explanation:
Soft fork: Official definition: A temporary fork in the block chain which commonly occurs when miners using non-upgraded nodes violate A new cons Ensus rule their nodes don ' t know about. (When new consensus rules are released, nodes that do not upgrade will have temporary forks because they do not know the new consensus rules and produce illegal chunks.) To be honest, the official definition feels a little blurry.
When the entire blockchain network, the system version or protocol upgrade, and the old version of the protocol is incompatible, then the upgraded new node can not accept the old node dug out of all or part of the block, because the new node of the calculation of large, so the old node dug out of the block no chance to be recognized, The blocks generated by the old nodes will eventually be considered as short-chain and discarded, and the new and old nodes always work on the same chain, which is known as soft forks. New node requirements are much stricter than older nodes.
Hard fork: Official definition: A permanent divergence in the the The block chain, commonly occurs when non-upgraded nodes can ' t validate blocks Crea Ted by upgraded nodes that follow newer consensus rules. (The blockchain is permanently divided, and after the new consensus rule is released, some nodes that are not upgraded cannot verify the chunks that have been made by the upgraded nodes, usually hard forks occur.) ）
When the entire blockchain network, the system version or protocol upgrade, and the old version of the Protocol is incompatible, the old node is not upgraded to accept the new node dug up all or part of the block, resulting in the emergence of two chains, assuming that the new node of the calculation of a large, new nodes in the maintenance of a chain, the old node has always maintained a chain If at this time most of the nodes are beginning to upgrade to the new version, then the old node maintenance chain can survive depends on how much power, this is called a hard fork.
Obviously, the most superficial understanding is the soft fork or a chain, the hard fork will be divided into two chains.
There are over-forks in Ethereum and Bitcoin, and what are the pros and cons of soft forks and hard forks in practical applications for real-world applications:
The soft fork has only one chain (the simplest and most straightforward), and the start does not require that all nodes in the blockchain be upgraded in a unified time, which allows for gradual escalation and does not affect the stability and effectiveness of the system in the soft fork process. But the soft fork has another premise is that the old non-upgraded node to be able to accept the new node generated chunks, which requires the system to be forward-compatible (forward compatible, this and generally we are using the software backward compatibility is the opposite way, requires new blocks to the old system to leave a room, to ensure compatibility), In fact, let the old node admit the new block, is actually a kind of deception, so that the old node can not detect the actual changes, which also violates the single-point integrity verification.
There have been instances of soft and hard forks in Ethereum and bitcoin:
The DAO in 2016 the hacker passed the Splitdao function recursive send mode vulnerability had stolen 3.6 million Ethereum, Splitdao function at the end of execution to modify the user's balance and turnover, if able to return to Splitdao processing operations, Make multiple operation calls to the etheric currency, then repeatedly transfer the etheric currency to another account. (Specific code analysis to see Shang big God's Blockchain technical guide P210 or online http://blog.csdn.net/sportshark/article/details/51820008), because the code vulnerability can not be modified after the release of DAO, to help Ethereum, Ethereum originally used soft fork, locked the DAO account, not allowed to trade, frozen ethereum, here you can find that the soft fork is actually in the Ethereum software binding rules, so that the hacker's etheric currency can not be traded, so that does not affect the rest of Ethereum normal transactions, Do not roll back the blockchain data (the impact of rollback is unimaginable). When implementing the soft Fork scheme, the DAO-related address is checked on each ethereum transaction, and if the transaction is rejected in connection with DAO, it locks all funds, but the scheme does not charge the transaction gas, and once the attacker initiates a large number of invalid transactions at a cost of 0, the network is paralysed. Finally, each node rolls back the software version, the soft fork fails, and then the hard fork is implemented, the following image:
Hard Fork Scheme in 1880000 block the DAO contract in the other L list, in 1920000 block, design an unconventional state change, forcing the L all address balance to a refund address, so that the majority of the DAO currency can be swapped back to the etheric currency, the final hard fork success, In the figure above 1920000 block, the left is the block number, the right is a hash value, the line represents a new chain, the node after the upgrade are in the new chain of accounting, no upgraded nodes in the old chain accounting.
Now ethereum in order to distinguish the new chain-eth, the old chain etc, two chain except DAO involves part of the same software code, History account fork before the same, address and private key is the same, ancient capital is legal. (There are also replay attacks, as well as reference to the Shang great god P216).
Also in Bitcoin, there has been a soft fork (http://ns2.btckan.com/news/topic/29027 Shing, the Great God also has video commentary, Youku and Babbitt have, can search under. This article is written in very detailed, the author directly copied over. P2sh Soft fork upgrade, P2sh included in the BIP16, through the soft fork to upgrade the Bitcoin system, so that bitcoin on the basis of support P2PKH, and then support a standard transaction type called P2SH. Prior to this, Bitcoin has supported the following script: "op_hash160 [20-byte-hash-value] op_equal". To spend this kind of script you just need to push the hash value of the original data (preimage) onto the (push data) stack.
P2sh is a more stringent restriction on the above conditions, in the P2SH mode (new node), you not only need to provide the hash value of the original data, but also to ensure that:
The original data is an executable script;
The script execution results return: true;
The script cannot contain the "push data" operation;
and some other restrictions;
When a new node that supports P2SH is deployed, the >50% of the new node (>=55% required for P2SH upgrade), the system will be in the following state of operation: When the P2SH transaction is forwarded to the old node, it is identified by the old node as a non-standard transaction (with new or incomprehensible op_ CODE), the old node does not accept, do not pack, do not forward; when the block containing the P2SH transaction is broadcast to the old node, the old node accepts the block and validates the P2SH transaction according to the original rules, as long as the old rules verify that the hash of the original data is equal (apparently equal) The old node creates a script output that has the original data: 123456, and spends that output. The old nodes were able to accept. But when broadcasting to a new node, press the new rule (must be script ...). ) does not pass, the new node refuses to accept, is considered illegal, will not package the transaction. Even if the transaction is packaged by an older node, it will be rejected by the new node. Because the new node controls most of the calculation, such transactions will never take effect; the system maintains a chain at the same time.
Upgrade details for P2sh:
Miners who support P2sh are required to include the words "/p2sh/" in their coinbase transactions;
All chunks (approximately 1000) within 1 weeks prior to the February 1, 2012 check, if more than 550 contain (about 55%) are activated p2sh.
Segwit Soft Fork Upgrade
Segwit is mainly included in the bip141-144, through the soft fork to upgrade the Bitcoin system, so that Bitcoin supports a series of Segwit feature sets. The details of the quarantine witness are described in the section on Block Connection (21): The segregated testimony of Bitcoin.
A soft fork upgrade requires the old node to identify the new transaction as non-standard, but at the same time legal. How is the quarantine witness done? The answer is: Anyone-can-spend's output trade.
Anyone-can-spend:
Here is an example of a anyone-can-spend:
Scriptpubkey: (empty)
To spend this kind of output, you only need to provide such a signature script:
Scriptsig:op_true
The isolation witness combines the script version (scripts versioning) and anyone-can-spend perfectly. The output of a standard P2wpkh is as follows:
scriptpubkey:0 <20-byte-key-hash> (0x0014{20-byte-key-hash})
The beginning of 0 will be the version number of the script in the new node, which is an anyone-can-spend output in the old node.
When a new node that supports Segwit is deployed, the >50% of the new node (Segwit requires >=95% when upgrading), the system will be in the following state of operation:
Segwit transaction is forwarded to the old node, the old node will be identified as non-standard transaction (anyone-can-spend), the old node is not accepted, not packaged, not forwarded;
When a block containing a segwit transaction is broadcast to an old node, the old node accepts the block and validates the Segwit transaction according to the original rules, and the result is passed (because it is available to anyone);
The old node tries to spend Segwit trading because it is available to anyone who can spend it. The old nodes were able to accept. When broadcasting to a new node, however, the new rule (the Quarantine Witness validation rule) does not pass, the new node refuses to accept it, it is considered illegal, and the transaction is not packaged. Even if the transaction is packaged by an older node, it will be rejected by the new node. Because the new node controls most of the calculation, such transactions will never be effective;
The system maintains a chain at the same time.
Upgrade details for Segwit:
Upgrade to core 0.13.1 and above support Segwit;
November 2017 If 95% calculates the force support, then activates the Segwit.
Refer to the network and blockchain technical guide, analysis of soft fork and hard fork, during the period also saw another article, Http://www.8btc.com/tan90d97 interested readers can understand, this specific to the chaos of hard fork trading data structure is analyzed.
Reprinted from: https://blog.csdn.net/sxjinmingjie/article/details/77621311
