Blockchain exception handling method and computer-readable medium

Abstract

This application discloses a blockchain exception handling method and computer-readable medium. The method includes: when a block consensus anomaly is detected, determining a blockchain state change set based on the current block height and a preset block number, where the preset block number represents the number of blocks that need to be cached for block status, and the blockchain state change set includes a range of block heights corresponding to the block status cache; then, based on the blockchain state change set, obtaining historical blockchain state data corresponding to the current block height to be detected from a designated storage location; then executing a test transaction based on the historical blockchain state data to obtain a test execution result of the test transaction; and finally, if the test execution result indicates that the test transaction was executed normally, rolling back the blockchain state to the historical block state data corresponding to the current block height to be detected. The technical solution of this application significantly reduces the amount of data cached for exception handling and reduces the storage space occupied by blockchain exception handling.

Description

Technical Field

[0001] The present application belongs to the field of blockchain technology, and specifically relates to a blockchain exception handling method and computer-readable medium. Background Art

[0002] As a distributed system, blockchain allows different nodes to jointly participate in computations, witness the execution of transactions, and confirm the final results. State deviation between blockchain nodes is a serious consensus anomaly, which can be caused by a variety of factors, including operating system vulnerabilities, storage layer vulnerabilities, and vulnerabilities in the blockchain program itself.

[0003] The core consensus process of the blockchain requires consistency checks on the status of nodes. The consistency check usually involves calculating hash fingerprints of the consensus ledger change mapping set and comparing them. Status deviations between nodes will lead to consensus failure and the blockchain cannot operate normally.

[0004] The current solution to consensus failures is to generate snapshots of the data stored at the corresponding block height at regular intervals. This snapshot is a direct copy of the stored data. Because snapshots are implemented by copying data, each snapshot is equivalent to a full copy of the data at the current block height. Therefore, the amount of data corresponding to the snapshot is large, occupying excessive storage space.

[0005] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to ordinary technicians in this field. Summary of the Invention

[0006] The purpose of this application is to provide a blockchain exception handling method and computer-readable medium to reduce the storage space occupied by blockchain exception handling.

[0007] Other features and advantages of the present application will become apparent from the following detailed description, or may be learned in part by practice of the present application.

[0008] According to one aspect of an embodiment of the present application, a blockchain exception handling method is provided, comprising:

[0009] When a block consensus anomaly is detected, a blockchain state change set is determined based on the current block height and a preset block size, where the preset block size represents the number of blocks that require block state caching, and the blockchain state change set includes the block height range corresponding to the block state cache;

[0010] According to the blockchain state change set, obtain the historical blockchain state data corresponding to the current block height to be detected from the specified storage location;

[0011] Executing a test transaction based on the historical blockchain state data to obtain a test execution result of the test transaction;

[0012] If the test execution result indicates that the test transaction is executed normally, the blockchain state is rolled back to the historical block state data corresponding to the current block height to be tested.

[0013] According to one aspect of an embodiment of the present application, a blockchain exception handling device is provided, comprising:

[0014] A change set determination module is configured to, when a block consensus anomaly is detected, determine a blockchain state change set based on the current block height and a preset block size, wherein the preset block size represents the number of blocks that require block state caching, and the blockchain state change set includes a block height range corresponding to the block state cache;

[0015] A state acquisition module is used to obtain historical blockchain state data corresponding to the current block height to be detected from a specified storage location based on the blockchain state change set;

[0016] A testing module, configured to execute a test transaction based on the historical blockchain state data and obtain a test execution result of the test transaction;

[0017] A state rollback module is configured to roll back the blockchain state to the historical block state data corresponding to the current block height to be tested if the test execution result indicates that the test transaction is executed normally.

[0018] In one embodiment of the present application, the status acquisition module is specifically configured to:

[0019] Determine the current block height to be detected based on the blockchain state change set; wherein the initial value of the current block height to be detected is the block height in the blockchain state change set that is closest to the current block height;

[0020] Obtain historical blockchain status data corresponding to the current block height to be detected from a specified file system; wherein the specified file system is a file system independent of the blockchain primary storage, and the blockchain primary storage is used to store data generated during the blockchain operation process.

[0021] In one embodiment of the present application, the status acquisition module is further configured to:

[0022] If the historical blockchain state data corresponding to the current block height to be detected is not cached in the designated file system, the historical blockchain state data corresponding to the current block height to be detected is obtained from the blockchain main storage.

[0023] In one embodiment of the present application, the status acquisition module is specifically configured to:

[0024] According to the blockchain state change set, the undetected block height closest to the detected block height is used as the current block height to be detected.

[0025] In one embodiment of the present application, the apparatus further comprises:

[0026] A return module is configured to return to the step of obtaining historical blockchain state data corresponding to the current block height to be tested from a specified storage location based on the blockchain state change set if the test execution result indicates that the test transaction failed to execute normally.

[0027] In one embodiment of the present application, the apparatus further comprises:

[0028] The abnormality prompt module is used to output blockchain abnormality prompt information if the test execution result indicates that the test transaction fails to execute normally and there is no undetected block height in the blockchain state change set.

[0029] In one embodiment of the present application, the apparatus further comprises:

[0030] The data caching module is used to obtain the blockchain status data of the current block when detecting the generation of the current block; and update the historical blockchain status data cached in the designated storage location according to the blockchain status data of the current block.

[0031] In one embodiment of the present application, the data cache module is specifically configured to:

[0032] Serializing the blockchain state data of the current block to obtain serialized state data;

[0033] Remove the historical blockchain state data corresponding to the block height farthest from the current block height from the historical blockchain state data cached in the designated storage location, and cache the serialized state data in the designated storage location.

[0034] In one embodiment of the present application, the apparatus further comprises:

[0035] A cleaning module is used to periodically clear the blockchain state data cached in the designated storage location that is not in the blockchain state change set through an automated cleaning process.

[0036] According to one aspect of an embodiment of the present application, a computer-readable medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the blockchain exception handling method in the above technical solution is implemented.

[0037] According to one aspect of an embodiment of the present application, an electronic device is provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor executes the executable instructions so that the electronic device performs the blockchain exception handling method in the above technical solution.

[0038] According to one aspect of an embodiment of the present application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain exception handling method described in the above technical solution.

[0039] In the technical solution provided in the embodiment of the present application, when a block consensus anomaly is detected, a blockchain state change set is determined based on the current block height and a preset block quantity, the preset block quantity indicating the number of blocks that need to be cached for the block state, and the blockchain state change set including the block height range corresponding to the block state cache; then, based on the blockchain state change set, the historical blockchain state data corresponding to the current block height to be detected is obtained from a designated storage location; then, a test transaction is executed based on the historical blockchain state data to obtain a test execution result of the test transaction; finally, if the test execution result indicates that the test transaction is executed normally, the blockchain state is rolled back to the historical block state data corresponding to the current block height to be detected. Thus, when a blockchain consensus anomaly occurs, it is only necessary to perform a test transaction based on the historical blockchain state data in the blockchain state change set cached in the designated storage location to restore normality. That is, the data involved in the exception processing is only the historical blockchain state data in the blockchain state change set, and there is no need to store the full amount of data during the blockchain operation process in the form of a snapshot, thereby greatly reducing the amount of data cached for exception processing and reducing the storage space occupied by blockchain exception processing.

[0040] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The accompanying drawings are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and those skilled in the art can derive other drawings based on these drawings without inventive effort.

[0042] Figure 1 The following schematically shows the architecture of a blockchain network using the technical solution of the present application.

[0043] Figure 2 The following schematically illustrates a flowchart of a blockchain exception handling method provided by one embodiment of the present application.

[0044] Figure 3 The diagram schematically shows a block provided by an embodiment of the present application.

[0045] Figure 4 A schematic diagram of blockchain status data provided by one embodiment of the present application is schematically shown.

[0046] Figure 5 The following schematically illustrates a flowchart of a blockchain exception handling method provided by one embodiment of the present application.

[0047] Figure 6 The following schematically illustrates a flowchart of a blockchain exception handling method provided by one embodiment of the present application.

[0048] Figure 7 The flowchart of the data caching process provided by one embodiment of the present application is schematically shown.

[0049] Figure 8 The figure schematically shows a flow chart of a self-healing protocol process provided by an embodiment of the present application.

[0050] Figure 9 The structural block diagram of the blockchain exception handling device provided in an embodiment of the present application is schematically shown.

[0051] Figure 10 The figure schematically shows a block diagram of a computer system structure of an electronic device suitable for implementing the embodiments of the present application. DETAILED DESCRIPTION

[0052] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this application will be thorough and complete and will fully convey the concepts of the example embodiments to those skilled in the art.

[0053] In addition, described feature, structure or characteristic can be combined in one or more embodiments in any suitable manner.In the following description, many specific details are provided so as to provide a full understanding of the embodiments of the present application. However, it will be appreciated by those skilled in the art that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps etc. can be adopted. In other cases, known methods, devices, implementations or operations are not shown or described in detail to avoid blurring the various aspects of the application.

[0054] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically separate entities. That is, these functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0055] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, while others may be combined or partially combined. Therefore, the actual execution order may vary depending on the actual situation.

[0056] Figure 1 The following schematically shows the architecture of a blockchain network using the technical solution of the present application.

[0057] See also Figure 1 The blockchain network shown in FIG. 100 may include multiple nodes 101. Multiple nodes 101 may refer to various clients in the blockchain network. The client may be a terminal device or a server.

[0058] During normal operation, each node 101 can receive input information and maintain shared data within the blockchain network based on the received input information. To ensure information interoperability within the blockchain network, information connections can exist between each node in the blockchain network, and nodes can transmit information through such information connections. For example, when any node in the blockchain network receives input information, other nodes in the blockchain network obtain the input information according to the consensus algorithm and store the input information as data in the shared data, so that the data stored on all nodes in the blockchain network is consistent.

[0059] During blockchain operation, different nodes in the blockchain network may inconsistently record the current block state, resulting in a state deviation anomaly. For example, in a four-node blockchain network, due to an anomaly at block height M, the four nodes write different values ​​to state k1: Node 0: k1="a"; Node 1: k1="c"; Node 2: k1="d"; Node 3: k1="e". At block height N (N greater than M), triggered by an external transaction, the blockchain nodes re-access the value of k1 and execute subsequent logic based on k1 to generate or modify other blockchain states. Ultimately, upon consensus, the states k1 of each node are inconsistent, resulting in state deviation, causing the blockchain to malfunction. This state deviation requires repair, and this application proposes a blockchain anomaly handling method. The blockchain anomaly handling method provided by this application is described in detail below, along with specific implementations.

[0060] Figure 2 The flowchart of the blockchain exception handling method provided by one embodiment of the present application is schematically shown. The specific implementation process of the method is described below using the nodes in the blockchain as the execution subject. Figure 2 As shown, the blockchain exception handling method provided in the embodiment of the present application includes steps 210 to 240, which are specifically as follows:

[0061] Step 210: When a block consensus anomaly is detected, a blockchain state change set is determined based on the current block height and a preset block quantity. The preset block quantity represents the number of blocks that need to be cached for the block state. The blockchain state change set includes a block height range corresponding to the block state cache.

[0062] Specifically, a blockchain is a chain composed of a series of blocks. In addition to recording the data of the current block, each block also records the hash value of the previous block, forming a chain in this way. Figure 3 As shown, a block consists of a block header and a block body. The block header includes important fields such as the block height h and the hash value PrevHash of the previous block, while the block body mainly stores transaction data.

[0063] As a distributed system, blockchain allows different nodes to jointly participate in computations, witness transactions, and confirm final results. The process of coordinating these loosely coupled, mutually distrusting participants to establish trust, ensure consistency, and maintain continuous collaboration can be abstracted as the consensus process. Common consensus algorithms include Proof of Work, Proof of Stake, PBFT, and RAFT. Block consensus anomalies occur when the consensus process within a blockchain network fails due to various reasons, preventing nodes in the network from reaching a consensus on the validity of a block.

[0064] A blockchain transaction is a user's request for an operation on the blockchain. Transactions are initiated by users and sent from their client to blockchain nodes. Upon receipt, the nodes package the transactions into blocks for consensus and execution. In addition to basic blocks and transactions, blockchains also store smart contracts and their states. The state data generated during smart contract execution is confirmed by a consensus mechanism and distributed across blockchain nodes. This data is globally consistent, verifiable, and tamper-proof, and is known as the world state. Block state, short for blockchain state, is a record of the blockchain's global data at a specific block height. As can be seen, each block height corresponds to a specific block state. As can be seen, both world state and block state represent the state of data in a blockchain network. While the two are related, they are not identical. The world state is a global concept encompassing the aggregate state of all accounts in the blockchain and is updated with each transaction. The block state refers to the state of the blockchain at a specific block height. In other words, the block state represents the global state of the blockchain at a specific point in time. The block state is updated with each new block, reflecting the latest state of the blockchain. In general, the world state is accumulated by all block states. The state of each block is part of the world state, and the world state is the sum of all block states.

[0065] The preset block size refers to the number of blocks that require block state caching. Here, block state caching refers to the corresponding blockchain state data. The preset block size can be a value such as 5 or 10. The blockchain state change set refers to the range of block heights corresponding to the block state cache. Assuming the current block height is BLK and the preset block size is M, the blockchain state change set can be expressed as [BLK-M+1, BLK]. For example, assuming the current block height is 1000 and the preset block size is 10, the blockchain state change set can be expressed as [991, 1000], indicating that the block height range for which blockchain state data is cached is from block height 991 to block height 1000, a total of 10 block heights.

[0066] Step 220: According to the blockchain state change set, obtain the historical blockchain state data corresponding to the current block height to be detected from the specified storage location.

[0067] Specifically, the current block height to be checked is a block height selected from the blockchain state change set. Generally, the current block height is the block height where the anomaly occurred. Therefore, the initial value of the current block height to be checked is the block height in the blockchain state change set closest to the current block height, equivalent to the block height immediately preceding the current block height. The designated storage location is where blockchain state data is stored. Historical blockchain state data is the blockchain state data stored in the designated storage location. This stored state data is typically already generated state data, hence the term "historical blockchain state data."

[0068] The blockchain state data corresponding to a block height is also called the ledger change mapping set of the block corresponding to the block height. When a blockchain node executes a block, driven by block transactions, the world state changes from one state to another. These operations that change the world state can ultimately be converted into key-value (KV) pair operations. The set of KV key-value pairs of all transactions in a block is called the block ledger change mapping set, which is the blockchain state data corresponding to a block height. For example, Figure 4 As shown in the figure, a block height corresponds to a ledger change mapping set. The ledger change mapping set represents state data in the form of key-value pairs, that is, a key-value pair represents a state (State), where the key (Key) corresponds to a specific state value (Value). For example, the state variable of a smart contract can be used as a key, and its value stores the current state of the variable. A ledger change mapping set includes multiple key-value pairs, for example, Figure 4 As shown, in block height 1, the state value corresponding to key1 is "helloworld", and the state value corresponding to key2 is 111.

[0069] Step 230: Execute a test transaction based on the historical blockchain state data to obtain a test execution result of the test transaction.

[0070] Specifically, a test transaction can be triggered by the current node or sent to the execution node by another node. A test transaction can be a randomly constructed transaction. When executing a test transaction, the blockchain node uses the historical blockchain state data corresponding to the current block to be tested as the basis for the block state. This is equivalent to the blockchain node rolling back the system state to the historical blockchain state data corresponding to the current block to be tested before executing the test transaction. The test execution result corresponding to the test transaction can also reflect whether the test transaction can be executed normally. The test transaction execution process includes the packaging and execution of the test transaction, and the blockchain's execution of the consensus mechanism based on the transaction execution result. Problems in any of these steps indicate that the test transaction cannot be executed normally.

[0071] Step 240: If the test execution result indicates that the test transaction is executed normally, the blockchain state is rolled back to the historical block state data corresponding to the current block height to be tested.

[0072] Specifically, if the execution result of the test transaction indicates that the test transaction can be executed normally, it means that the blockchain can perform correct consensus operations based on the historical blockchain state data corresponding to the current block height to be detected, which means that the historical blockchain state data corresponding to the current block height to be detected is correct. At this time, the blockchain state is rolled back to the historical block state data corresponding to the current block height to be detected. The subsequent blockchain nodes continue to execute transactions based on the historical block state data corresponding to the current block height to be detected, thereby eliminating the erroneous blockchain state data and realizing the repair of blockchain state deviation.

[0073] In the technical solution provided in the embodiment of the present application, when a block consensus anomaly is detected, a blockchain state change set is determined based on the current block height and a preset block quantity, the preset block quantity indicating the number of blocks that need to be cached for the block state, and the blockchain state change set including the block height range corresponding to the block state cache; then, based on the blockchain state change set, the historical blockchain state data corresponding to the current block height to be detected is obtained from a designated storage location; then, a test transaction is executed based on the historical blockchain state data to obtain a test execution result of the test transaction; finally, if the test execution result indicates that the test transaction is executed normally, the blockchain state is rolled back to the historical block state data corresponding to the current block height to be detected. Thus, when a blockchain consensus anomaly occurs, it is only necessary to perform a test transaction based on the historical blockchain state data in the blockchain state change set cached in the designated storage location to restore normality. That is, the data involved in the exception processing is only the historical blockchain state data in the blockchain state change set, and there is no need to store the full amount of data during the blockchain operation process in the form of a snapshot, thereby greatly reducing the amount of data cached for exception processing and reducing the storage space occupied by blockchain exception processing.

[0074] Figure 5 The flowchart of the blockchain exception handling method provided by one embodiment of the present application is schematically shown. This embodiment is a further refinement of the above embodiment. Figure 5 As shown, the blockchain exception handling method provided in the embodiment of the present application includes the following steps:

[0075] Step 510: When a block consensus anomaly is detected, a blockchain state change set is determined based on the current block height and a preset block quantity. The preset block quantity represents the number of blocks that need to be cached for the block state. The blockchain state change set includes a block height range corresponding to the block state cache.

[0076] The specific implementation process of step 510 can refer to the relevant description in the aforementioned step 210, which will not be repeated here.

[0077] Step 520: Determine the current block height to be detected based on the blockchain state change set; wherein the initial value of the current block height to be detected is the current block height.

[0078] Specifically, the block heights of undetected state data in the blockchain state change set are all recorded as undetected block heights, and correspondingly, the block heights of detected state data are recorded as detected block heights. The detected state data mentioned here refers to executing a test transaction based on the corresponding state data, and judging whether the transaction can be executed normally at this time based on the execution result. The current block height to be detected is one of the undetected block heights in the blockchain state change set. Initially, all block heights in the blockchain state change set are undetected block heights, that is, the current block height is also an undetected block height. Here, the initial value of the current block height to be detected is set to the current block height, that is, detection starts from the current block height. Optionally, in other embodiments, the block height corresponding to the left endpoint of the blockchain state change set can also be used as the current block height to be detected. For example, the blockchain state change set is recorded as [BLK-M+1, BLK], and the initial value of the current block height to be detected can be set to BLK-M+1.

[0079] In one embodiment of the present application, if at least one detection has been performed, then when determining the current block height to be detected, it is necessary to use the undetected block height closest to the detected block height as the current block height to be detected based on the blockchain state change set. In short, the block height before the current detected block height is used as the next block height to be detected. If the initial value of the current block height to be detected is the current block height, then the current detected block height is subtracted by 1 to obtain the current block height to be detected; if the initial value of the current block height to be detected is the block height corresponding to the left endpoint of the blockchain state change set, then the current detected block height is added by 1 to obtain the current block height to be detected. Exemplarily, the blockchain state change set is recorded as [BLK-M+1, BLK]. If the detection starts from the block height BLK, after the block height BLK is detected, the next block height to be detected is BLK-1; if the detection starts from the block height BLK-M+1, after the block height BLK-M+1 is detected, the next block height to be detected is BLK-M.

[0080] Step 530: Obtain historical blockchain status data corresponding to the current block height to be detected from a specified file system; wherein the specified file system is a file system independent of the blockchain primary storage, and the blockchain primary storage is used to store data generated during the operation of the blockchain.

[0081] Specifically, when obtaining the historical blockchain state data corresponding to the current block height to be detected, the corresponding data is preferentially obtained from the designated file system. The designated file system is a file system used to store blockchain state data and is independent of the blockchain primary storage. That is, the designated file system and the blockchain primary storage are two independent data storage spaces. Among them, the blockchain primary storage is used to store data generated during the operation of the blockchain. In other words, the data generated during the operation of the blockchain is generally stored in the blockchain primary storage.

[0082] In one embodiment of the present application, if the designated file system does not cache the historical blockchain status data corresponding to the current block height to be detected, the corresponding status data cannot be obtained from the designated file system. However, since the blockchain primary storage stores all data generated during the operation of the blockchain, the historical blockchain status data corresponding to the current block height to be detected can be obtained from the blockchain primary storage at this time.

[0083] It can be seen that the historical blockchain state data corresponding to the current block height to be detected is not only stored in the specified file system, but also in the blockchain main storage. This means that the blockchain state data corresponding to the blockchain state change set adopts a dual persistence strategy, which effectively ensures that the corresponding state data can be obtained during exception processing, thereby improving the reliability of state deviation repair.

[0084] Step 540: Execute a test transaction based on the historical blockchain state data to obtain a test execution result of the test transaction.

[0085] The specific implementation process of step 540 can refer to the relevant description of step 230 above and will not be repeated here. If the test execution result indicates that the test transaction is executed normally, then the process proceeds to step 550; if the test execution result indicates that the test transaction is not executed normally, then the process proceeds to step 560.

[0086] Step 550: If the test execution result indicates that the test transaction is executed normally, the blockchain state is rolled back to the historical block state data corresponding to the current block height to be tested.

[0087] The specific implementation process of step 550 can refer to the relevant description in the aforementioned step 240, which will not be repeated here.

[0088] Step 560: If the test execution result indicates that the test transaction failed to execute normally, return to the step of obtaining the historical blockchain state data corresponding to the current block height to be tested from the specified storage location based on the blockchain state change set.

[0089] Specifically, if the test execution result indicates that the test transaction failed to execute normally, it means that based on the historical blockchain state data corresponding to the current block height to be detected, the correct consensus operation cannot be performed, which means that the historical blockchain state data corresponding to the current block height to be detected is wrong. At this time, the state deviation has not been repaired and exception handling needs to be continued. Therefore, return to step 520 and perform state detection based on the next block height to be detected.

[0090] In one embodiment of the present application, if the test execution result indicates that the test transaction failed to execute normally and there is no undetected block height in the blockchain state change set, it means that the next block height to be detected has exceeded the block height range specified by the blockchain state change set. At this time, it indicates that the state deviation of the blockchain is relatively serious and cannot be handled by a simple state rollback. Therefore, a blockchain abnormality prompt message is output to facilitate the user to handle it in a targeted manner.

[0091] In the technical solution provided in the embodiments of the present application, based on the blockchain state change set, the current block height to be detected is determined and the corresponding historical blockchain state data is obtained from the specified file system to perform a test transaction. When the test transaction is executed normally, the state is rolled back to repair the state deviation. When the test transaction is abnormal, the detection of the next block height in the blockchain state change set is continued until the test transaction is normal. Therefore, in most scenarios, only a very small amount of data corresponding to the blockchain state change set needs to be cached to achieve the purpose of restoring the abnormal state, effectively reducing the storage space occupied by blockchain exception handling.

[0092] In one embodiment of the present application, before obtaining the historical blockchain status data corresponding to the current block height to be detected from the designated storage location, the technical solution of the present application also includes a caching process of the blockchain status data, specifically: when the generation of the current block is detected, the blockchain status data of the current block is obtained; and the historical blockchain status data cached in the designated storage location is updated according to the blockchain status data of the current block.

[0093] In this embodiment, the total amount of state data cached in the designated storage location is the total amount of state data corresponding to a preset number of blocks. For example, if the preset number of blocks is 10, the designated storage location caches the state data corresponding to the latest 10 blocks. When the generation of the current block is detected, the historical blockchain state data corresponding to the preset number of blocks cached in the designated storage location needs to be updated based on the blockchain state data of the current block to ensure that the historical blockchain state data cached in the designated storage location is the latest blockchain state data for the preset number of blocks.

[0094] When updating data, the blockchain state data for the current block is first serialized to obtain serialized state data. Serialization here refers to converting the blockchain state data into binary data for easier storage. Then, from the historical blockchain state data cached in the designated storage location, the historical blockchain state data corresponding to the block height farthest from the current block height is removed, and the serialized state data is cached in the designated storage location. For example, the designated storage location currently caches historical blockchain state data corresponding to the block height range [990, 999], and the current block height is 1000. When a block with a block height of 1000 is generated, the historical blockchain state data corresponding to the block height farthest from the current block height, namely, block height 900, is removed from the designated storage location. Then, the serialized state data for block height 1000 is cached in the designated storage location. As a result, the designated storage location now caches the historical blockchain state data corresponding to the block heights [991, 1000]. It should be understood that if a block consensus anomaly is detected during the generation of the current block height, the blockchain state data corresponding to the current block height does not need to be cached at this time.

[0095] In one embodiment of the present application, the process of updating the state data in a designated storage location may include: using an automated cleanup process to periodically clear the blockchain state data cached in the designated storage location that is not included in the blockchain state change set. In this case, after a new block is generated, the blockchain node can directly cache the blockchain state data corresponding to the new block in the designated storage location, but there is no need to remove the historical blockchain state data corresponding to the block height farthest from the current block height. In this case, a dedicated automated cleanup process is also required. Each time a new block is generated, a new blockchain state change set can be determined based on the block height of the new block and a preset block size. The automated cleanup process is then used to periodically clear the blockchain state data cached in the designated storage location that is not included in the blockchain state change set. For example, at time t, the designated storage location caches historical blockchain state data corresponding to the block height range [990, 999]. After a period of time T, i.e., at time t+T, the current block height is 1005, and the new blockchain state change set is [996, 1005]. At this time, the designated storage location caches historical blockchain state data corresponding to the block height range [990, 1005]. Assuming T is the execution period of the automated cleanup process, the automated cleanup process will clear the historical blockchain state data corresponding to the block height range [990, 995] from the designated storage location, leaving only the historical blockchain state data corresponding to the block height range [996, 1005] in the designated storage location. This effectively prevents the designated storage location from caching too much data and maintains the system's storage efficiency.

[0096] It should be noted that the above-mentioned designated storage location for caching historical blockchain status data is a designated file system independent of the blockchain main storage, that is, the data in the designated file system needs to be updated without clearing the data in the blockchain main storage.

[0097] The following is a specific example to illustrate the implementation process of the technical solution of this application.

[0098] Figure 6 The flowchart of the blockchain exception handling method provided by one embodiment of the present application is schematically shown. Figure 6 As shown, the blockchain exception handling method provided in the embodiment of the present application includes the following process:

[0099] In this embodiment, data caching is required. Data caching refers to caching the historical blockchain status data corresponding to the latest M blocks through a specified file system, where M is the preset block size. Figure 6 As shown, when the block corresponding to block height N+1 is generated, a block consensus anomaly is detected. At this time, the designated file system caches the historical blockchain status data corresponding to the M blocks before block height N+1, that is, the status data from block height N+M+1 to block height N. The data before this, such as the blocks corresponding to block height NM-1 and block height NM, are expired blocks. The corresponding data can be deleted from the designated file system through the cleanup thread.

[0100] When caching state data, a state change set is generated based on the current block height N and the preset block quantity M. The state change set here is the blockchain state change set, that is, the historical blockchain state data corresponding to the most recent M blocks.

[0101] The historical blockchain state data corresponding to the state change set is persisted to the specified file system. Persistence means storage. The historical blockchain state data corresponding to each block height forms an independent file in the specified file system.

[0102] Continue to refer Figure 6 When a block consensus anomaly is detected at block height N+1, the data of the first M blocks cached in the specified file system is used for state recovery. The state recovery process is to execute a test transaction based on the historical blockchain state data and obtain the test execution result of the test transaction. When the test execution result indicates that the test transaction is executed normally, the blockchain state is rolled back to the historical block state data corresponding to the current block height to be detected.

[0103] Figure 7 The following is a flow chart schematically illustrating a data caching process provided by an embodiment of the present application. The data caching process includes the following steps:

[0104] S7-1. Set the latest block height of the current blockchain to BLK. The system will generate a block state change set for the latest M blocks, where M is a pre-configured parameter, i.e., the preset number of blocks, which defines the coverage range of the block state change set [BLK-M+1, BLK].

[0105] S7-2. Start the automatic cleanup process to clear the status data that exceeds the current range.

[0106] S7-3. After a new block is generated through the consensus mechanism, the ledger state change mapping set in the block is extracted.

[0107] S7-4. Serialize the extracted ledger state change mapping set (the serialization process here refers to the process of converting data in memory into binary data to facilitate data storage. Data serialization and deserialization are two basic operations in data processing, which are responsible for converting data objects into a format that can be stored or transmitted, and restoring this format to the original data object, respectively.) and store it persistently in a designated file system independent of the main storage (blockchain data is stored in the file system). The state change mapping set of each block is stored in a separate file.

[0108] S7-5. The automated cleanup process regularly checks and removes block states that are beyond the snapshot range to maintain the system's storage efficiency.

[0109] S7-6. Repeat step S7-3 to continuously update the ledger state snapshot set.

[0110] When the blockchain system runs abnormally, a self-healing protocol process is implemented to automatically restore the system to normal state. Figure 8 As shown in FIG, the self-healing protocol process includes the following steps:

[0111] S8-1. Set the latest block height of the current blockchain to BLK. The system default parameter M defines the range of the block state change set, namely [BLK-M+1, BLK]. When a system anomaly is detected, set the recovery target block height RECOVERY_BLK, with an initial value of BLK.

[0112] S8-2. The blockchain node enters the self-healing mode and performs status recovery operations.

[0113] S8-3, the node is in self-healing mode, and the node is preferentially connected to the specified file system (i.e. Figure 8 If the required data is not available in the specified file system, it is loaded from the blockchain main storage.

[0114] S8-4. By sending a test transaction (each blockchain has its own way of sending transactions, which varies from system to system. The test transaction here is just a simple transaction that is randomly constructed to determine whether the blockchain can execute the transaction and thus determine whether the blockchain status has been successfully restored), the monitoring node has resumed normal operation and verified whether the blockchain's consensus mechanism, transaction packaging and execution are normal.

[0115] S8-5. If the node returns to normal, it indicates that the self-healing operation is successful and the system status rolls back to the block high RECOVERY_BLK.

[0116] S8-6: If the node is still in an abnormal state, decrement RECOVERY_BLK and return to S8-3 to repeat the self-healing process until RECOVERY_BLK exceeds the preset block state change set coverage range [BLK-M+1, BLK]. If it exceeds this range, the self-healing operation is considered to have failed and an abnormal prompt message is output.

[0117] For example, assume the blockchain's latest block height is 1000. At block height 992, a program exception (bug) causes inconsistent writes of a certain state value for a smart contract x across different nodes. This state value is re-accessed at block height 1001, resulting in inconsistent consensus and, therefore, a block consensus anomaly is detected. Set the cached block size M to 10, meaning the ledger change mappings for the most recent 10 blocks are cached. The blockchain state change set at the time of the anomaly is [991, 1000].

[0118] The self-healing process of the blockchain is as follows:

[0119] 1. Fix the anomaly of the blockchain program itself and then turn on the self-healing mode.

[0120] 2. The blockchain node starts in self-healing mode and obtains a preset cached block size M of 10.

[0121] 3. Each node in the blockchain accesses the historical blockchain status data at block height 1000 in the specified file system. At this time, the status of smart contract x is still abnormal (all status values ​​formed after the abnormal value are abnormal values). The external party discovers that the blockchain consensus status is still abnormal by sending a test transaction.

[0122] 4. The blockchain lowers the block height and starts accessing the historical blockchain status data at block height 999. Recovery still fails, and the block height continues to decrease until the block height reaches 991.

[0123] 5. The blockchain accesses the state of block height 991. At this time, the state of smart contract x is the normal state value before the exception. By sending a test transaction externally and finding that the transaction is executed successfully, the blockchain state is rolled back to the state of block height 991, and the blockchain state is successfully restored.

[0124] In this application's technical solution, there's no need to back up blockchain state and other data using snapshots or the full world state. Instead, only the block ledger change mapping data for the latest M blocks is cached. This balance between the amount of buffered data and the probability of recovering from an abnormal state is achieved through configurable options. In most scenarios, only a minimal amount of cached data is needed to recover from an abnormal state, effectively reducing the storage space occupied by blockchain exception handling.

[0125] It should be noted that although the steps of the method of the present application are described in a specific order in the drawings, this does not require or imply that the steps must be performed in this specific order, or that all steps must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0126] The following describes an embodiment of the device of the present application, which can be used to execute the blockchain exception handling method in the above embodiment of the present application. Figure 9 The following schematically shows the structural block diagram of the blockchain exception handling device provided by the embodiment of the present application. Figure 9 As shown, the blockchain exception handling device provided in the embodiment of the present application includes:

[0127] A change set determination module 910 is configured to determine a blockchain state change set based on the current block height and a preset block size when a block consensus anomaly is detected. The preset block size represents the number of blocks that require block state caching, and the blockchain state change set includes a block height range corresponding to the block state cache.

[0128] A state acquisition module 920 is configured to acquire historical blockchain state data corresponding to the current block height to be detected from a specified storage location based on the blockchain state change set;

[0129] A testing module 930 is configured to execute a test transaction based on the historical blockchain state data and obtain a test execution result of the test transaction;

[0130] The state rollback module 940 is configured to roll back the blockchain state to the historical block state data corresponding to the current block height to be tested if the test execution result indicates that the test transaction is executed normally.

[0131] In one embodiment of the present application, the status acquisition module 920 is specifically configured to:

[0132] Determine the current block height to be detected based on the blockchain state change set; wherein the initial value of the current block height to be detected is the block height in the blockchain state change set that is closest to the current block height;

[0133] Obtain historical blockchain status data corresponding to the current block height to be detected from a specified file system; wherein the specified file system is a file system independent of the blockchain primary storage, and the blockchain primary storage is used to store data generated during the blockchain operation process.

[0134] In one embodiment of the present application, the status acquisition module 920 is further configured to:

[0135] If the historical blockchain state data corresponding to the current block height to be detected is not cached in the designated file system, the historical blockchain state data corresponding to the current block height to be detected is obtained from the blockchain main storage.

[0136] In one embodiment of the present application, the status acquisition module 920 is specifically configured to:

[0137] According to the blockchain state change set, the undetected block height closest to the detected block height is used as the current block height to be detected.

[0138] In one embodiment of the present application, the apparatus further comprises:

[0139] A return module is configured to return to the step of obtaining historical blockchain state data corresponding to the current block height to be tested from a specified storage location based on the blockchain state change set if the test execution result indicates that the test transaction failed to execute normally.

[0140] In one embodiment of the present application, the apparatus further comprises:

[0141] The abnormality prompt module is used to output blockchain abnormality prompt information if the test execution result indicates that the test transaction fails to execute normally and there is no undetected block height in the blockchain state change set.

[0142] In one embodiment of the present application, the apparatus further comprises:

[0143] The data caching module is used to obtain the blockchain status data of the current block when detecting the generation of the current block; and update the historical blockchain status data cached in the designated storage location according to the blockchain status data of the current block.

[0144] In one embodiment of the present application, the data cache module is specifically configured to:

[0145] Serializing the blockchain state data of the current block to obtain serialized state data;

[0146] Remove the historical blockchain state data corresponding to the block height farthest from the current block height from the historical blockchain state data cached in the designated storage location, and cache the serialized state data in the designated storage location.

[0147] In one embodiment of the present application, the apparatus further comprises:

[0148] A cleaning module is used to periodically clear the blockchain state data cached in the designated storage location that is not in the blockchain state change set through an automated cleaning process.

[0149] The specific details of the blockchain exception handling device provided in each embodiment of the present application have been described in detail in the corresponding method embodiments and will not be repeated here.

[0150] Figure 10 The block diagram schematically shows a computer system structure of an electronic device used to implement an embodiment of the present application.

[0151] It should be noted that Figure 10 The computer system 1000 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0152] like Figure 10 As shown, computer system 1000 includes a central processing unit (CPU) 1001, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1002 or programs loaded from storage 1008 into random access memory (RAM) 1003. RAM 1003 also stores various programs and data required for system operation. CPU 1001, ROM 1002, and RAM 1003 are connected to each other via bus 1004. An input / output interface (I / O interface) 1005 is also connected to bus 1004.

[0153] The following components are connected to the input / output interface 1005: an input section 1006 including a keyboard, mouse, and the like; an output section 1007 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and speakers; a storage section 1008 including a hard disk; and a communication section 1009 including a network interface card such as a local area network card or a modem. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to the input / output interface 1005 as needed. Removable media 1011, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 1010 as needed, so that computer programs read from the removable media can be installed in the storage section 1008 as needed.

[0154] In particular, according to an embodiment of the present application, the processes described in the various method flow charts can be implemented as computer software programs. For example, an embodiment of the present application includes a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for executing the methods shown in the flow charts. In such an embodiment, the computer program can be downloaded and installed from a network via the communication portion 1009 and / or installed from a removable medium 1011. When the computer program is executed by the central processing unit 1001, the various functions defined in the system of the present application are performed.

[0155] It should be noted that the computer-readable medium described in the embodiments of this application may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more conductors, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal transmitted in baseband or as part of a carrier wave, which carries computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0156] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0157] It should be noted that, although several modules or units of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiment of the application, the features and functions of two or more modules or units described above can be concretized in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into multiple modules or units to be concretized.

[0158] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes a number of instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.

[0159] Those skilled in the art will readily appreciate other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of this application and include common knowledge or customary techniques in the art that are not disclosed herein.

[0160] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A blockchain exception handling method, characterized in that: include: When a block consensus anomaly is detected, a blockchain state change set is determined based on the current block height and a preset block size, where the preset block size represents the number of blocks that require block state caching, and the blockchain state change set includes the block height range corresponding to the block state cache; According to the blockchain state change set, obtain the historical blockchain state data corresponding to the current block height to be detected from the specified storage location; Executing a test transaction based on the historical blockchain state data to obtain a test execution result of the test transaction; If the test execution result indicates that the test transaction is executed normally, the blockchain state is rolled back to the historical block state data corresponding to the current block height to be tested.

2. The blockchain exception handling method according to claim 1, characterized in that: According to the blockchain state change set, the historical blockchain state data corresponding to the current block height to be detected is obtained from the specified storage location, including: Determine the current block height to be detected based on the blockchain state change set; wherein the initial value of the current block height to be detected is the block height in the blockchain state change set that is closest to the current block height; Obtain historical blockchain status data corresponding to the current block height to be detected from a specified file system; wherein the specified file system is a file system independent of the blockchain primary storage, and the blockchain primary storage is used to store data generated during the blockchain operation process.

3. The blockchain exception handling method according to claim 2, characterized in that: The method further comprises: If the historical blockchain state data corresponding to the current block height to be detected is not cached in the designated file system, the historical blockchain state data corresponding to the current block height to be detected is obtained from the blockchain main storage.

4. The blockchain exception handling method according to claim 2, characterized in that: Determine the current block height to be detected based on the blockchain state change set, including: According to the blockchain state change set, the undetected block height closest to the detected block height is used as the current block height to be detected.

5. The blockchain exception handling method according to claim 1, characterized in that: After executing a test transaction based on the historical blockchain state data and obtaining a test execution result of the test transaction, the method further includes: If the test execution result indicates that the test transaction failed to execute normally, the process returns to the step of obtaining historical blockchain state data corresponding to the current block height to be tested from a specified storage location according to the blockchain state change set.

6. The blockchain exception handling method according to claim 5, characterized in that: The method further comprises: If the test execution result indicates that the test transaction failed to execute normally and there is no undetected block height in the blockchain state change set, a blockchain abnormality prompt message is output.

7. The blockchain exception handling method according to claim 1, characterized in that: Before obtaining the historical blockchain state data corresponding to the current block height to be detected from the designated storage location, the method further includes: When detecting that a current block has been generated, obtaining blockchain status data of the current block; The historical blockchain status data cached in the designated storage location is updated according to the blockchain status data of the current block.

8. The blockchain exception handling method according to claim 7, characterized in that: Updating the historical blockchain state data cached in the designated storage location according to the blockchain state data of the current block includes: Serializing the blockchain state data of the current block to obtain serialized state data; Remove the historical blockchain state data corresponding to the block height farthest from the current block height from the historical blockchain state data cached in the designated storage location, and cache the serialized state data in the designated storage location.

9. The blockchain exception handling method according to claim 7, characterized in that: The method further comprises: Through an automated cleanup process, blockchain state data cached in the designated storage location that is not in the blockchain state change set is periodically cleared.

10. A computer-readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the blockchain exception handling method according to any one of claims 1 to 9 is implemented.

Images