Method for handling blockchain fork, electronic device, and storage medium

Abstract

The present application provides a method for handling blockchain forks, an electronic device, and a computer-readable storage medium. The method includes: in response to a fork instruction for a target sub-chain within a target business contract on an initial main chain, a first node determines to generate a forked main chain corresponding to the target sub-chain and stops processing transactions of the target business contract; wherein, the first node is a consensus node carrying the initial main chain; a second node processes transactions of the target business contract to update the target sub-chain, and when the number of sub-chain blocks updated by the target sub-chain reaches a preset quantity threshold, the updated sub-chain blocks are sent to the first node; the second node is a consensus node carrying the forked main chain; the first node records the transaction voucher information of the sub-chain blocks into the initial main chain. In the solution of the present application, a large number of first nodes maintain the initial main chain, and the initial main chain records the transaction voucher information of the sub-chain blocks, ensuring the credibility of the target sub-chain.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and particularly to a method for handling blockchain forks, an electronic device, and a computer-readable storage medium. Background Art

[0002] A blockchain fork refers to the splitting of another blockchain based on the original blockchain. Common forks include hard forks and soft forks caused by changes in the blockchain protocol. Among them, in the case of a hard fork, nodes that have not upgraded the protocol cannot be forward-compatible with nodes that have upgraded the protocol. At this time, nodes that have not upgraded the protocol and nodes that have upgraded the protocol respectively maintain a blockchain, and a permanent fork occurs in the blockchain. In the case of a soft fork, the upgraded protocol still conforms to the old protocol. Therefore, nodes that have not upgraded the protocol can be compatible with nodes that have upgraded the protocol. At this time, a temporary fork occurs in the blockchain, and subsequently, nodes that have not upgraded the protocol and nodes that have upgraded the protocol will re-maintain the same unique blockchain. In addition, the blockchain may also fork due to business development needs. For example, as the business grows, the data volume of a single blockchain becomes too large, and another blockchain needs to be split out to reduce the data volume of the single blockchain.

[0003] However, after a blockchain fork occurs, the number of consensus nodes participating in a single blockchain will decrease, resulting in a decline in the credibility of the blockchain. For some credit-related businesses, the decline in the credibility of the blockchain will further lead to obstacles in business development. Summary of the Invention

[0004] The purpose of the embodiments of this application is to provide a method for handling blockchain forks, an electronic device, and a computer-readable storage medium, which are used to maintain the credibility of the forked blockchain after the blockchain forks.

[0005] On the one hand, this application provides a method for handling blockchain forks, including:

[0006] In response to a fork instruction for a target sub-chain within a target business contract on the initial main chain, the first node determines to generate a forked main chain corresponding to the target sub-chain and stops processing transactions of the target business contract; wherein, the first node is a consensus node carrying the initial main chain;

[0007] The second node processes transactions of the target business contract to update the target sub-chain. When the number of sub-chain blocks updated in the target sub-chain reaches a preset quantity threshold, the updated sub-chain blocks are sent to the first node; wherein, the second node is a consensus node carrying the forked main chain;

[0008] The first node records the transaction voucher information of the updated sub-chain blocks into the initial main chain.

[0009] In one embodiment, before the method responds to a forking instruction for a target sub-chain within a target business contract on the initial main chain, the method further includes:

[0010] The first node constructs a temporary main-chain block according to multiple transactions sent to multiple business contracts on the initial main chain;

[0011] The first node divides the multiple transactions into several transaction sets according to the transaction addresses of the multiple transactions within the temporary main-chain block, and distributes each transaction set to the corresponding business contract for processing;

[0012] The first node receives the transaction voucher information corresponding to the transaction sets returned by several business contracts after executing the transactions, and constructs a candidate main-chain block according to the transaction voucher information of each transaction set and the temporary main-chain block;

[0013] The first node conducts consensus based on the candidate main-chain block to update the initial main chain.

[0014] In one embodiment, before the first node receives the transaction voucher information corresponding to the transaction sets returned by several business contracts after executing the transactions, the method further includes:

[0015] For each business contract on the initial main chain that receives a transaction set, the first node processes the transactions within the transaction set through the business contract to obtain several transaction execution results;

[0016] For each business contract on the initial main chain that receives a transaction set, the first node constructs the current sub-chain block of the sub-chain within the business contract by using the several transaction execution results obtained through processing by the business contract, the transaction set corresponding to the business contract, and the transaction voucher information of a sub-chain block on the sub-chain within the business contract;

[0017] For each business contract on the initial main chain that receives a transaction set, the first node calculates the transaction voucher information of the current sub-chain block of the business contract through the business contract, and submits the transaction voucher information of the current sub-chain block to the first node.

[0018] In one embodiment, the first node processes the transactions within the transaction set through the business contract, including:

[0019] When any transaction involves a specified business contract on the initial main chain, the first node queries through the business contract by invoking the specified business contract, and processes to obtain the transaction execution result of the transaction based on the query result; wherein, the specified business contract is any business contract other than the business contract that receives the transaction; or,

[0020] The first node initiates a modification transaction to the designated business contract through the business contract, and obtains a transaction execution result of the transaction based on the modification result.

[0021] In one embodiment, before the first node records the transaction voucher information of the updated sub-chain block to the initial main chain, the method further includes:

[0022] The first node verifies the updated sub-chain block.

[0023] In one embodiment, the first node verifies the updated subchain block, including:

[0024] For each updated subchain block, the first node executes a number of transactions in each subchain block through the contract code of the target business contract and obtains a number of transaction execution results;

[0025] The first node calculates the corresponding transaction voucher information for each subchain block through a number of transactions in each subchain block, a number of transaction execution results corresponding to the transactions, and the transaction voucher information of the previous subchain block of each subchain block; wherein the transaction voucher information of the previous subchain block of the first updated subchain block is recorded in the initial main chain;

[0026] For each updated sub-chain block, the first node determines whether the transaction voucher information calculated for the sub-chain block is consistent with the original voucher information corresponding to the sub-chain block. If they are consistent, it is determined that the verification is passed; wherein the original voucher information is the transaction voucher information calculated by the second node for the sub-chain block.

[0027] In one embodiment, after the first node records the transaction voucher information of the updated sub-chain block to the initial main chain, the method further includes:

[0028] In response to a migration instruction for a target subchain in a target business contract on the forked main chain, the second node submits all designated subchain blocks on the target subchain to the first node; wherein the designated subchain blocks are subchain blocks updated after the target subchain is forked from the initial main chain;

[0029] The first node verifies the original certificate information of all designated sub-chain blocks, and if the verification passes, writes all designated sub-chain blocks into the initial main chain;

[0030] The first node restarts processing the transaction of the target business contract.

[0031] In one embodiment, the method further comprises:

[0032] The first node or the second node returns a query result in response to a transaction data query request for any local business contract.

[0033] In one embodiment, the second node processes transactions of the target business contract to update the target sub-chain, including:

[0034] The second node issues a number of transactions sent to the target business contract to the target business contract;

[0035] The second node processes the number of transactions through the target business contract to obtain a number of transaction execution results;

[0036] The second node constructs the current sub-chain block of the target sub-chain through the target business contract with the number of transactions, the number of transaction execution results, and the transaction voucher information of the previous sub-chain block on the target sub-chain to update the target sub-chain.

[0037] On the other hand, the present application provides an electronic device, which includes:

[0038] A processor;

[0039] A memory for storing instructions executable by the processor;

[0040] Wherein, the processor is configured to execute the above-mentioned method for processing blockchain forks.

[0041] In addition, the present application provides a computer-readable storage medium, which stores a computer program that can be executed by a processor to complete the above-mentioned method for processing blockchain forks.

[0042] In the solution of the present application, after the target sub-chain of the target business contract forks from the initial main chain, the first node carrying the initial main chain no longer processes transactions of the target business contract; the second node carrying the forked main chain can, after updating the target sub-chain and when the number of updated sub-chain blocks reaches a quantity threshold, send the updated sub-chain blocks to the first node; the first node can record the transaction voucher information of the updated sub-chain blocks to the initial main chain;

[0043] Since a large number of first nodes maintain the initial main chain, after the data of the target business contract is stripped from the initial main chain, the transaction voucher information of the sub-chain blocks of the target sub-chain can still be synchronously recorded to the initial main chain, enabling the transaction data of the target business contract to obtain the credit endorsement of a large number of first nodes and ensuring the credibility of the target sub-chain. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments of the present application.

[0045] Figure 1 Schematic diagram of the application scenario of the blockchain fork processing method provided by an embodiment of the present application;

[0046] Figure 2 Schematic diagram of the structure of the electronic device provided by an embodiment of the present application;

[0047] Figure 3 Schematic diagram of the blockchain deployment architecture provided by an embodiment of the present application;

[0048] Figure 4 Schematic flow chart of the blockchain update method provided by an embodiment of the present application;

[0049] Figure 5 Schematic flow chart of the sub-chain update method provided by an embodiment of the present application;

[0050] Figure 6 Schematic flow chart of the blockchain fork processing method provided by an embodiment of the present application;

[0051] Figure 7 Schematic flow chart of the sub-chain update method provided by another embodiment of the present application;

[0052] Figure 8 Schematic flow chart of the sub-chain block verification method provided by an embodiment of the present application;

[0053] Figure 9 Schematic flow chart of the blockchain migration processing method provided by an embodiment of the present application. Detailed implementation manners

[0054] Next, the technical solutions in the embodiments of the present application will be described with reference to the accompanying drawings in the embodiments of the present application.

[0055] Similar reference numerals and letters denote similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of the present application, the terms "first", "second", etc. are only used for descriptive distinction and cannot be construed as indicating or implying relative importance.

[0056] Figure 1 Schematic diagram of the application scenario of the blockchain fork processing method provided by an embodiment of the present application. As Figure 1As shown in the figure, the application scenario includes multiple consensus nodes 20 of a blockchain network. The consensus nodes 20 can be computer hosts, servers, server clusters, virtual machines, etc. The consensus nodes 20 can carry an initial main chain and act as the first nodes; the consensus nodes 20 can also carry a forked main chain and act as the second nodes. Since the forked main chain is forked from the initial main chain, the number of consensus nodes 20 carrying the forked main chain is less than the number of consensus nodes 20 carrying the initial main chain. When the consensus node 20, as the second node, updates the sub-chain of the business contract on the forked main chain, it can send the updated sub-chain block to the consensus node 20 acting as the first node. When the consensus node 20, as the first node, receives the updated sub-chain block, it can record the transaction voucher information of the sub-chain block on the initial main chain.

[0057] As Figure 2 shown, this embodiment provides an electronic device 1, including: at least one processor 11 and a memory 12. Figure 2 Taking one processor 11 as an example. The processor 11 and the memory 12 are connected through a bus 10. The memory 12 stores instructions executable by the processor 11. When the instructions are executed by the processor 11, the electronic device 1 can execute all or part of the processes of the methods in the following embodiments. In one embodiment, the electronic device 1 can be the above-mentioned consensus node 20 for executing the processing method of blockchain forking.

[0058] The memory 12 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM for short), electrically erasable programmable read-only memory (EEPROM for short), erasable programmable read-only memory (EPROM for short), programmable read-only memory (PROM for short), read-only memory (ROM for short), magnetic memory, flash memory, magnetic disk or optical disc.

[0059] This application also provides a computer-readable storage medium storing a computer program that can be executed by the processor 11 to complete the processing method of blockchain forking provided by this application.

[0060] See Figure 3 , which is a schematic diagram of a blockchain deployment architecture provided by an embodiment of this application. As Figure 3As shown in the figure, the Ethereum Virtual Machine (EVM) serving as a consensus node carries the blockchain main chain and multiple business contracts. Each business contract can use the account model of Ethereum, including contract accounts and token accounts. The contract account of a business contract can include the account balance, contract code, and account storage content. The account storage content can include the transactions processed by the business contract and the sub-chain constructed by the business contract based on its own transactions. The token account can include the account balance. Figure 3 In the figure, Business Contract 1 maintains Sub-chain 1, and each block of Sub-chain 1 records the transactions processed by Business Contract 1; Business Contract 2 maintains Sub-chain 2, and each block of Sub-chain 2 records the transactions processed by Business Contract 2; and so on. Each business contract maintains a sub-chain.

[0061] The blocks in the blockchain main chain can record the transactions of the blocks in the sub-chain and the transaction voucher information of the sub-chain blocks. Here, the transaction voucher information can be the hash value corresponding to the sub-chain block. Exemplarily, the transaction voucher information can be saved in the blocks of the blockchain main chain in the form of key-value; where the key is the address of the business contract plus the sub-chain block height, used to indicate the unique sub-chain block under the unique business contract; and the value is the hash value of the sub-chain block. In sequence, each block of the blockchain main chain records the transactions of the sub-chain blocks in each sub-chain. As Figure 3 shown in the figure, Block 1 in the main chain can record the transactions in Sub-chain Block 1 of Sub-chain 1, the transactions in Sub-chain Block 1 of Sub-chain 2... Block 2 in the main chain can record the transactions in Sub-chain Block 2 of Sub-chain 1, the transactions in Sub-chain Block 2 of Sub-chain 2... Block 3 in the main chain can record the transactions in Sub-chain Block 3 of Sub-chain 1, the transactions in Sub-chain Block 3 of Sub-chain 2... and so on. As the blockchain main chain is updated, the blockchain main chain can record the transactions processed by each business contract.

[0062] The blockchain architecture of this application can be flexibly forked and merged as the business changes, and the credibility of the blockchain after forking is ensured.

[0063] See Figure 4 , which is a schematic flowchart of the blockchain update method provided by an embodiment of this application. As Figure 4 shown in the figure, the method can include Step 410 - Step 430.

[0064] Step 410: The first node constructs a temporary main chain block according to multiple transactions sent to multiple business contracts on the initial main chain.

[0065] Among them, the initial main chain is the blockchain main chain before forking, and the initial main chain is maintained by a large number of consensus nodes. There can be multiple business contracts on the initial main chain. In other words, the transactions of multiple business contracts are Figure 3The architecture pattern shown is recorded on the initial main chain. The first node is a consensus node carrying the initial main chain.

[0066] When any one of the first nodes can receive multiple transactions sent by an external account to multiple business contracts on the initial main chain, it can construct a temporary main chain block based on the multiple transactions. Here, the temporary main chain block is a temporary block for packing the transactions to be recorded on the initial main chain; since multiple first nodes carrying the initial main chain can receive multiple transactions sent to business contracts simultaneously, and the transactions have timeliness in the blockchain network, therefore, the transaction contents in the temporary main chain blocks constructed by different first nodes may vary.

[0067] Step 420: The first node divides the multiple transactions into several transaction sets according to the transaction addresses of the multiple transactions in the temporary main chain block, and distributes each transaction set to the corresponding business contract for processing.

[0068] The first node can divide the multiple transactions into several transaction sets according to the transaction address of each transaction in the multiple transactions. The transaction addresses of the transactions in each transaction set are the same. For each transaction set, the first node can distribute the transaction set to the corresponding business contract for processing.

[0069] Exemplarily, after the first node constructs a temporary main chain block for the 100 received transactions, it divides the 100 transactions into 3 transaction sets according to the transaction addresses, and then sends the first transaction set containing 30 transactions to business contract 1, the second transaction set containing 35 transactions to business contract 2, and the third transaction set containing 35 transactions to business contract 3.

[0070] Step 430: The first node receives the transaction voucher information corresponding to the transaction set returned by several business contracts after executing the transactions, and constructs a candidate main chain block according to the transaction voucher information of each transaction set and the temporary main chain block.

[0071] Step 440: The first node conducts consensus based on the candidate main chain block to update the initial main chain.

[0072] After receiving the transaction set, each business contract can execute the transactions in the transaction set and return the transaction voucher information corresponding to the transaction set. After the first node distributes the transaction set to several local business contracts, it can receive the transaction voucher information returned by each business contract. The first node can write the transaction voucher information of each transaction set into the temporary main chain block, thereby constructing a candidate main chain block. Here, the candidate main chain block is a candidate block to be added to the initial main chain; the candidate main chain block may also include the hash value of the previous main chain block on the initial main chain.

[0073] After the first node constructs a candidate main-chain block, it can determine a new main-chain block from the candidate main-chain blocks determined by several first nodes through a consensus mechanism with other first nodes, and add the new main-chain block to the initial main chain. Here, the consensus mechanism can be: the first nodes compare multiple transaction voucher information in the candidate main-chain blocks with each other. If any candidate main-chain block has the same multiple transaction voucher information as the candidate main-chain blocks generated by a preset proportion (such as 0.5 or 0.7, etc.) of other first nodes in the blockchain network, it indicates that consensus is reached, and this candidate main-chain block is the new main-chain block.

[0074] For a specific first node, after consensus, the new main-chain block added to the initial main chain may be constructed by this first node or sent by other first nodes.

[0075] Through the above measures, after the execution of the transactions in the business contract, the transactions and transaction voucher information can be written into the initial main chain maintained by a large number of consensus nodes, obtaining the credit endorsement of a large number of consensus nodes and ensuring the credibility of various businesses.

[0076] In one embodiment, refer to Figure 5 , which is a schematic flowchart of the sub-chain update method provided by an embodiment of this application. As Figure 5 shown, this method may include step 510 - step 530.

[0077] Step 510: For each business contract that receives a transaction set on the initial main chain, the first node processes the transactions in the transaction set through the business contract to obtain several transaction execution results.

[0078] For any business contract that receives a transaction set, the first node can process each transaction in the transaction set through the business contract respectively to obtain the transaction processing result corresponding to the transaction. Here, the transaction processing result can be a state machine. After each transaction in the transaction set is processed, several transaction execution results can be obtained.

[0079] The first node can execute the transactions in its corresponding transaction set through each business contract, so as to obtain several transaction execution results corresponding to each business contract. Exemplarily, the first node processes 30 transactions in the first transaction set one by one through business contract 1 to obtain 30 transaction execution results; the first node processes 35 transactions in the second transaction set one by one through business contract 2 to obtain 35 transaction execution results; the first node processes 35 transactions in the third transaction set one by one through business contract 3 to obtain 35 transaction execution results.

[0080] Step 520: For each business contract that has received a transaction set on the initial main chain, the first node constructs the current sub-chain block within the business contract through the business contract using the several transaction execution results obtained through processing, the transaction set corresponding to the business contract, and the transaction voucher information of a sub-chain block on the sub-chain within the business contract.

[0081] For each business contract that has received a transaction set, after obtaining several transaction execution results, the first node can construct the current sub-chain block through the transaction set corresponding to the business contract, the several transaction execution results, and the transaction voucher information (hash value) of the previous sub-chain block within the sub-chain.

[0082] Exemplarily, there are already 100 sub-chain blocks in the sub-chain of business contract 1. After the first node executes 30 transactions in the transaction set through the business contract, it can construct the 101st sub-chain block based on the 30 transactions, the 30 transaction execution results corresponding to the 30 transactions, and the hash value of the 100th sub-chain block. Here, the 101st sub-chain block is the current sub-chain block of business contract 1.

[0083] Step 530: For each business contract that has received a transaction set on the initial main chain, the first node calculates the transaction voucher information of the current sub-chain block of the business contract through the business contract and submits the transaction voucher information of the current sub-chain block to the first node.

[0084] For each business contract that has received a transaction set, after the first node constructs the current sub-chain block through the business contract, it can calculate the hash value of the current sub-chain block. The first node submits the hash value, the contract address of the business contract, and the block height of the current sub-chain block to the first node in the form of key-value through the business contract.

[0085] Through this measure, each business contract that receives a transaction set can update the sub-chain it maintains after executing the transaction and submit the transaction voucher information of the updated sub-chain block to the first node, enabling the first node to update the initial main chain.

[0086] In an embodiment, when the first node processes the transactions in the transaction set through the business contract, some transactions may involve a specified business contract on the initial main chain. Here, the specified business contract is any business contract other than the business contract that receives the transaction. Exemplarily, if the transaction sent by the first node to business contract 1 involves business contract 2, then business contract 2 is the specified business contract.

[0087] At this time, when the first node executes the transaction through the business contract, it needs to call the specified business contract.

[0088] In one case, a transaction needs to be executed by relying on the query result of a specified business contract. The first node can call the specified business contract through the business contract to perform a query, and process the query result to obtain the transaction execution result of the transaction. Exemplarily, the currently received transaction is a business contract for counting the number of private enterprises in City A, and the specified business contract is a business contract for recording the number of private enterprises in each region of City A. After calling the specified business contract to obtain the number of private enterprises in each region, the total number of private enterprises in City A can be counted.

[0089] In another case, when a transaction is executed, the data in the specified business contract needs to be updated. The first node can initiate a modification transaction to the specified business contract through the business contract, and process the modification result to obtain the transaction execution result of the transaction. Exemplarily, the currently received transaction is a business contract for purchasing goods, and the specified business contract is a business contract for recording the goods information owned by the user. When executing the transaction of purchasing goods, it is necessary to call the specified business contract to modify the goods information owned by the user, so as to complete the transaction of purchasing goods.

[0090] Through the above measures, when the transaction processed by the business contract involves other business contracts, the transaction can be completed through internal calls.

[0091] See Figure 6 , which is a schematic flowchart of the method for handling blockchain forks provided by an embodiment of the present application. As Figure 6 shown, the method may include the following steps 610-step 630.

[0092] Step 610: In response to a fork instruction for a target sub-chain in a target business contract on the initial main chain, the first node determines to generate a fork main chain corresponding to the target sub-chain, and stops processing the transactions of the target business contract; wherein, the first node is a consensus node carrying the initial main chain.

[0093] The fork instruction is an instruction indicating to strip the data of the business contract from the initial main chain. The target business contract is a business contract whose transaction data needs to be stripped from the initial main chain. The target sub-chain is the sub-chain maintained by the target business contract. The fork main chain is the blockchain main chain that performs consensus on the transaction data of the target sub-chain.

[0094] As the business develops, the transaction data of the target business contract needs to be stripped from the initial main chain. For example: the target business contract involves user private data. To ensure data security, it is stripped from the initial main chain maintained by the enterprise server and transferred to be stored in the server of the government organization. Or, as the business on the initial main chain develops and grows, the transaction confirmation time on the initial main chain increases. To improve the transaction execution rate on the initial main chain, the target business contract on the initial main chain is stripped from the initial main chain and transferred to be stored in another blockchain. In this case, the blockchain deployer can issue a fork instruction.

[0095] After receiving the forking instruction, the first node can determine to generate a forking main chain. Subsequently, the consensus nodes carrying the forking main chain process the transactions of the target business contract. At this time, the first node stops processing the transactions of the target business contract. In other words, after receiving a transaction sent to the target business contract, the first node no longer puts it into the temporary main chain block, nor forwards the transaction or sends the transaction to the target business contract.

[0096] Exemplarily, there were originally business contract 1, business contract 2, and business contract 3 on the initial main chain. When the first node receives a forking instruction for the sub-chain of business contract 3, when subsequently receiving transactions sent to business contract 1, business contract 2, and business contract 3, the first node constructs a temporary main chain block for the transactions of business contract 1 and business contract 2, and divides the transactions in the temporary main chain block into a transaction set sent to business contract 1 and a transaction set sent to business contract 2.

[0097] Step 620: The second node processes the transactions of the target business contract to update the target sub-chain. When the number of sub-chain blocks updated in the target sub-chain reaches a preset quantity threshold, the updated sub-chain blocks are sent to the first node; where the second node is a consensus node carrying the forking main chain.

[0098] The second node carrying the forking main chain can process the transactions of the target business contract, thereby updating the target sub-chain of the target business contract. When the target sub-chain is updated, sub-chain blocks will be added. When the number of sub-chain blocks reaches the quantity threshold, the second node can send the updated sub-chain blocks to the first node. Here, the quantity threshold can be customized based on application requirements. Exemplarily, for every 5 sub-chain blocks updated in the target sub-chain, the second node can send 5 updated sub-chain blocks to the first node.

[0099] Step 630: The first node records the transaction voucher information of the updated sub-chain blocks into the initial main chain.

[0100] After receiving the updated sub-chain blocks, the first node can record the transaction voucher information of the updated sub-chain blocks into the initial main chain.

[0101] Compared with before the forking of the target sub-chain of the target business contract, after forking, only the transaction voucher information of the sub-chain blocks can be recorded on the initial main chain, without recording the transactions within the sub-chain blocks. In addition, the initial main chain can record the transaction voucher information after several main chain blocks at intervals.

[0102] Exemplarily, there are 100 main-chain blocks before the initial main chain forks. These 100 main-chain blocks record the transaction and transaction voucher information within the sub-chain blocks with block heights from 1 to 100 on the sub-chain of business contract 1, the transaction and transaction voucher information within the sub-chain blocks with block heights from 1 to 100 on the sub-chain of business contract 2, and the transaction and transaction voucher information within the sub-chain blocks with block heights from 1 to 100 on the sub-chain of business contract 3. After business contract 3 is split from the initial main chain, the 101st main-chain block of the initial main chain does not record the transactions of business contract 3. When the second node updates the sub-chain of business contract 3, after the sub-chain is updated with 5 sub-chain blocks, the second node can send the sub-chain blocks with block heights from 101 to 105 to the first node. The first node can record the hash values of these 5 sub-chain blocks as transaction voucher information into the 105th main-chain block. Subsequently, every time the sub-chain of business contract 3 is updated with 5 sub-chain blocks, the second node will send the updated sub-chain blocks to the first node, enabling the first node to add the transaction voucher information of the updated sub-chain blocks to the initial main chain.

[0103] Since after the blockchain forks, the transaction voucher information of the forked sub-chain can still be recorded in the initial main chain maintained by a large number of consensus nodes, the transaction data of the target business contract obtains the credit endorsement of a large number of consensus nodes and has sufficient credibility to ensure the normal development of the business.

[0104] In one embodiment, referring to Figure 7 , which is a schematic flowchart of the sub-chain update method provided in another embodiment of the present application. As Figure 7 shown, when the second node updates the target sub-chain, it can perform the following steps 621 - step 623.

[0105] Step 621: The second node distributes a number of transactions sent to the target business contract to the target business contract.

[0106] After the target sub-chain of the target business contract forks from the initial main chain, the second node can receive a number of transactions sent to the target business contract. The second node can construct a temporary main-chain block of the forked main chain based on the number of transactions and distribute the number of transactions in the temporary main-chain block to the target business contract.

[0107] Step 622: The second node processes the number of transactions through the target business contract to obtain a number of transaction execution results.

[0108] After the target business contract receives the number of transactions, the second node processes the number of transactions one by one through the target business contract to obtain a transaction execution result corresponding to each transaction, obtaining a number of transaction execution results. Here, the transaction execution result can be a state machine.

[0109] If a transaction processed by a target business contract involves other business contracts, the transaction can be completed by invoking other business contracts.

[0110] Step 623: The second node constructs the current sub-chain block of the target sub-chain with a number of transactions, a number of transaction execution results, and the transaction voucher information of a sub-chain block on the target sub-chain to update the target sub-chain through the target business contract.

[0111] After the target business contract finishes executing a number of transactions, the second node can construct the current sub-chain block with a number of transactions, a number of transaction execution results, and the transaction voucher information (hash value) of a sub-chain block on the target sub-chain through the target business contract. The second node can add the current sub-chain block to the target sub-chain through the target business contract.

[0112] Exemplarily, there are already 100 sub-chain blocks in the business sub-chain of the target business contract. After the second node executes 25 transactions through the target business contract, it can construct the 101st sub-chain block based on the 25 transactions, the 25 transaction execution results corresponding to the 25 transactions, and the hash value of the 100th sub-chain block. Here, the 101st sub-chain block is the current sub-chain block of the target business contract.

[0113] In addition, the target business contract can calculate the hash value of the current sub-chain block as the transaction voucher information of the current sub-chain block. The target business contract can submit the hash value of the current sub-chain block, the contract address of the target business contract, and the block height of the current sub-chain block to the second node in the form of key-value.

[0114] The second node can construct a candidate main-chain block of the forked main-chain based on the transaction voucher information and the temporary main-chain block returned by the target business contract. After constructing the candidate main-chain block, the second node can determine the new main-chain block of the forked main-chain from the candidate main-chain blocks determined by a number of second nodes through a consensus mechanism with other second nodes, and add the new main-chain block to the forked main-chain. The consensus mechanism can refer to the relevant description above and will not be elaborated here.

[0115] Through the above measures, the second node can update the forked main-chain and the target sub-chain under the target business contract.

[0116] In one embodiment, before recording the transaction voucher information of the updated sub-chain block to the initial main chain, the first node may verify the updated sub-chain block. By verifying the sub-chain block, the correctness of the transaction data within the sub-chain block can be determined. On the one hand, if the verification fails, the transaction data within the sub-chain block is abnormal, and the first node does not need to record the transaction voucher information of the sub-chain block to the initial main chain. On the other hand, if the verification passes, the transaction data within the sub-chain block is normal, and the first node can record the transaction voucher information of the sub-chain block to the initial main chain. The solution of this application does not limit the specific verification method of the sub-chain block, and any method that can verify the correctness of transaction data meets the requirements.

[0117] Exemplarily, referring to Figure 8 , which is a schematic flowchart of the verification method for the sub-chain block provided by an embodiment of this application. As Figure 8 shown, when the first node verifies the sub-chain block submitted by the second node, the following steps 631 to 633 can be executed.

[0118] Step 631: For each updated sub-chain block, the first node executes several transactions within each sub-chain block through the contract code of the target business contract to obtain several transaction execution results.

[0119] After the first node receives multiple sub-chain blocks of the forked target sub-chain, it can obtain the contract code from the target business contract, and then execute each transaction of each sub-chain block with this contract code to obtain the transaction execution result corresponding to each transaction.

[0120] Exemplarily, the first node receives sub-chain blocks with block heights from 101 to 105 on the target sub-chain, and each sub-chain block has 10 transactions. After executing each transaction in each sub-chain block, 50 transaction execution results can be obtained.

[0121] Step 632: The first node calculates the corresponding transaction voucher information for each sub-chain block one by one through several transactions within each sub-chain block, several transaction execution results corresponding to the several transactions, and the transaction voucher information of the previous sub-chain block of each sub-chain block; wherein, the transaction voucher information of the previous sub-chain block of the first updated sub-chain block is recorded in the initial main chain.

[0122] For any sub-chain block, after obtaining several transaction execution results within the sub-chain block, the first node can calculate the hash value based on the several transaction execution results, several transactions, and the transaction voucher information of the previous sub-chain block as the transaction voucher information of the sub-chain block.

[0123] Each time the first node receives multiple sub-chain blocks, the transaction voucher information of the previous sub-chain block of the first sub-chain block among them has been recorded in the initial main chain. After the first node can obtain the transaction voucher information of the previous sub-chain block from the initial main chain, it can calculate the transaction voucher information of the first sub-chain block. After obtaining the transaction voucher information of the first sub-chain block, the first node can continue to calculate the transaction voucher information of the second sub-chain block, and so on, to calculate the transaction voucher information of each sub-chain block.

[0124] Exemplarily, after the first node processes the transaction execution results of the transactions in the sub-chain blocks with block heights from 101 to 105 on the target sub-chain through the contract code of the target business contract, it can obtain the transaction voucher information (hash value) of the sub-chain block with block height 100 on the target sub-chain from the initial main chain, and calculate the transaction voucher information of the sub-chain block with block height 101 through this transaction voucher information, the transaction in the sub-chain block with block height 101, and the transaction execution result. The first node can calculate the transaction voucher information of the sub-chain block with block height 102 through the transaction voucher information of the sub-chain block with block height 101, the transaction in the sub-chain block with block height 102, and the transaction execution result. And so on, until the transaction voucher information of the sub-chain block with block height 105 is calculated.

[0125] Step 633: For each updated sub-chain block, the first node determines whether the calculated transaction voucher information for the sub-chain block is consistent with the original voucher information corresponding to the sub-chain block. If it is consistent, it is determined that the verification passes; wherein, the original voucher information is the transaction voucher information calculated by the second node for the sub-chain block.

[0126] When the second node submits the updated sub-chain blocks to the first node, the transaction voucher information (hash value) of the previous sub-chain block of each sub-chain block has been recorded in each sub-chain block, and this transaction voucher information is the original voucher information of the previous sub-chain block. In addition, the second node can also submit the original voucher information calculated for the last sub-chain block.

[0127] After calculating the transaction voucher information for the updated sub-chain block, the first node can determine whether this transaction voucher information is consistent with its original voucher information. On the one hand, if they are not consistent, it means that there is an error in the second node's processing of the transactions in the sub-chain block, and the sub-chain block fails the verification. On the other hand, if they are consistent, it means that the sub-chain block passes the verification.

[0128] Through the above measures, when the first node validates the sub-chain blocks, it can execute the transactions within the blocks based on the contract code of the target business contract, and perform the validation using the transaction execution results and the transaction voucher information of the previous sub-chain block. On the premise that the previous sub-chain block has been validated, if the transactions are processed normally, the original voucher information of the sub-chain block must be consistent with the transaction voucher information calculated by the first node. Therefore, the first node can effectively validate each sub-chain block.

[0129] In one embodiment, refer to Figure 9 , which is a schematic flowchart of the processing method for blockchain migration provided by an embodiment of the present application. As Figure 9 shown, the method may include the following steps 910 - step 930.

[0130] Step 910: In response to a migration instruction for a target sub-chain within a target business contract on a forked main chain, the second node submits all specified sub-chain blocks on the target sub-chain to the first node; wherein, the specified sub-chain blocks are the sub-chain blocks updated after the target sub-chain forks from the initial main chain.

[0131] The migration instruction may be an instruction to merge the data of the business contract into the initial main chain. The target business contract is the business contract whose transaction data needs to be migrated to the initial main chain. The target sub-chain is the sub-chain maintained by the target business contract.

[0132] As the business develops, the target sub-chain of the target business contract that has forked from the initial main chain may need to be merged back into the initial main chain. For example: The forked main chain is maintained by several enterprise servers, but the enterprises to which these enterprise servers belong no longer process relevant businesses subsequently. At this time, it is necessary to merge the transaction data of the target business contract on the forked main chain back into the initial main chain. Or, some businesses on the forked main chain are processed using a separate blockchain. At this time, the business volume of the forked main chain decreases, and the transaction data of the target business contract on the forked main chain can be merged back into the initial main chain.

[0133] After receiving the migration instruction, the second node can determine all the specified sub-chain blocks on the target sub-chain. The second node can determine the sub-chain blocks on the target sub-chain corresponding to the blocks on the forked main chain based on each block of the forked main chain. These sub-chain blocks are the specified sub-chain blocks updated after the target sub-chain forks from the initial main chain. The second node can submit all the specified sub-chain blocks on the target sub-chain to the first node.

[0134] Step 920: The first node validates the original voucher information of all the specified sub-chain blocks. If the validation passes, it writes all the specified sub-chain blocks into the initial main chain.

[0135] Step 930: The first node resumes processing the transactions of the target business contract.

[0136] The first node can obtain the transaction voucher information of the previously recorded specified sub-chain blocks from the initial main chain according to the block heights corresponding to each specified sub-chain block and the contract address of the target business contract. For each specified sub-chain block, the first node can determine whether the transaction voucher information of the specified sub-chain block is consistent with its corresponding original voucher information. On the one hand, if they are inconsistent, it indicates that there is an error in the specified sub-chain block submitted by the second node, and the verification of the specified sub-chain block fails. On the other hand, if they are consistent, it indicates that the verification of the specified sub-chain block passes. In this case, the first node can write the specified sub-chain block into the initial main chain. When constructing the next temporary main chain block for the initial main chain, the first node can put the specified sub-chain block that has passed the verification into the temporary main chain block, thereby writing the specified sub-chain block into the initial main chain.

[0137] After writing all the specified sub-chain blocks into the initial main chain and completing the migration of the transaction data of the target sub-chain, the first node can resume processing the transactions of the target business contract. In other words, the first node can process the transactions of the target business contract that have been merged into the initial main chain as usual through the aforementioned blockchain update method and sub-chain update method.

[0138] Through the above measures, the sub-chain of the forked business contract can be flexibly migrated to the initial main chain according to business requirements.

[0139] In an embodiment, both the first node and the second node can provide query interfaces for the transaction data of local business contracts. The blockchain deployer can issue a transaction data query request to the first node or the second node by calling the query interface. The transaction data query request can query information such as the number of transactions processed by a certain business contract, the number of users, and the transaction initiation time within a specified time period (such as within 24 hours, within half a year, etc.).

[0140] The first node or the second node that receives the transaction data query request can search for the corresponding transaction data from the local blockchain (main chain or sub-chain) and return the source of the transaction data query request.

[0141] Through this measure, the first node and the second node can conveniently provide the blockchain deployer with a transaction data query service, so that the blockchain deployer can timely adjust the blockchain architecture according to the query results and issue a forking instruction or a migration instruction.

Claims

1. A method for handling blockchain forks, characterized in that, it includes: In response to a fork instruction for a target sub-chain within a target business contract on the initial main chain, a first node determines to generate a forked main chain corresponding to the target sub-chain and stops processing transactions of the target business contract; wherein, the first node is a consensus node carrying the initial main chain; A second node processes transactions of the target business contract to update the target sub-chain. When the number of sub-chain blocks updated in the target sub-chain reaches a preset quantity threshold, the updated sub-chain blocks are sent to the first node; wherein, the second node is a consensus node carrying the forked main chain; The first node records the transaction voucher information of the updated sub-chain blocks into the initial main chain; Before the first node records the transaction voucher information of the updated sub-chain blocks into the initial main chain, the method further includes: For each updated sub-chain block, the first node executes several transactions within each sub-chain block through the contract code of the target business contract to obtain several transaction execution results; The first node calculates the corresponding transaction voucher information for each sub-chain block one by one through several transactions within each sub-chain block, several transaction execution results corresponding to the several transactions, and the transaction voucher information of the previous sub-chain block of each sub-chain block; wherein, the transaction voucher information of the previous sub-chain block of the first updated sub-chain block is recorded in the initial main chain; For each updated sub-chain block, the first node determines whether the transaction voucher information calculated for the sub-chain block is consistent with the original voucher information corresponding to the sub-chain block. If they are consistent, it is determined that the verification passes; wherein, the original voucher information is the transaction voucher information calculated by the second node for the sub-chain block.

2. The method according to claim 1, characterized in that, Before the response to the fork instruction for the target sub-chain within the target business contract on the initial main chain, the method further includes: The first node constructs a temporary main chain block according to multiple transactions sent to multiple business contracts on the initial main chain; The first node divides the multiple transactions into several transaction sets according to the transaction addresses of the multiple transactions within the temporary main chain block and distributes each transaction set to the corresponding business contract for processing; The first node receives the transaction voucher information corresponding to the transaction sets returned by several business contracts after executing the transactions, and constructs a candidate main chain block according to the transaction voucher information of each transaction set and the temporary main chain block; The first node conducts consensus based on the candidate main chain block to update the initial main chain.

3. The method according to claim 2, characterized in that, Before the first node receives the transaction voucher information corresponding to the transaction sets returned by several business contracts after executing the transactions, the method further includes: For each business contract on the initial main chain that receives a transaction set, the first node processes the transactions within the transaction set through the business contract to obtain several transaction execution results; For each business contract that receives a transaction set on the initial main chain, the first node constructs the current sub-chain block of the sub-chain within the business contract by using the several transaction execution results obtained through processing by the business contract, the transaction set corresponding to the business contract, and the transaction voucher information of a sub-chain block on the sub-chain within the business contract. For each business contract that receives a transaction set on the initial main chain, the first node calculates the transaction voucher information of the current sub-chain block of the business contract through the business contract, and submits the transaction voucher information of the current sub-chain block to the first node.

4. The method according to claim 3, wherein, the first node processes the transactions in the transaction set through the business contract, including: when any transaction involves a specified business contract on the initial main chain, the first node queries the specified business contract through the business contract and obtains the transaction execution result of the transaction based on the query result; wherein, the specified business contract is any business contract other than the business contract that receives the transaction; or, the first node initiates a modification transaction to the specified business contract through the business contract and obtains the transaction execution result of the transaction based on the modification result.

5. The method according to claim 1, wherein, after the first node records the transaction voucher information of the updated sub-chain block to the initial main chain, the method further includes: in response to a migration instruction for a target sub-chain within a target business contract on the forked main chain, the second node submits all specified sub-chain blocks on the target sub-chain to the first node; wherein, the specified sub-chain blocks are the sub-chain blocks updated after the target sub-chain forks from the initial main chain; the first node verifies the original voucher information of all specified sub-chain blocks, and if the verification passes, writes all specified sub-chain blocks to the initial main chain; the first node restarts processing the transactions of the target business contract.

6. The method according to claim 1, wherein, the method further includes: the first node or the second node returns a query result in response to a transaction data query request for any local business contract.

7. The method according to claim 1, wherein, the second node processes the transactions of the target business contract to update the target sub-chain, including: the second node distributes several transactions sent to the target business contract to the target business contract; the second node processes the several transactions through the target business contract to obtain several transaction execution results; the second node constructs the current sub-chain block of the target sub-chain through the target business contract by using the several transactions, the several transaction execution results, and the transaction voucher information of a sub-chain block on the target sub-chain to update the target sub-chain.

8. An electronic device, wherein, the electronic device includes: a processor; a memory for storing instructions executable by the processor; Wherein, the processor is configured to execute the method for processing blockchain fork according to any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, the storage medium stores a computer program, and the computer program can be executed by a processor to complete the method for processing blockchain fork according to any one of claims 1-7.

Images