Blockchain processing method and apparatus, and medium and computer program product

Abstract

Provided in the present disclosure are a blockchain processing method and apparatus, and a medium and a computer program product. The method is executed by a blockchain node in a blockchain network, and comprises: in response to an on-chain request of a block, on the basis of state update data of a corresponding transaction object in the block, obtaining object state data having a state data index; on the basis of the state data index, determining a full-storage blockchain node for storing the object state data; in response to a blockchain node being different from the full-storage blockchain node, sending the object state data to the full-storage blockchain node for storage; generating a first digest value of the object state data; receiving a query request for the object state data; and on the basis of the state data index, requesting the object state data and a storage serial number from the full-storage blockchain node, and verifying the object state data by using the first digest value.

Description

Blockchain processing methods, devices, media, and computer program products

[0001] This application claims priority to Chinese Patent Application No. 202411724770.0, filed on November 28, 2024, entitled "Blockchain Processing Method, Related Apparatus and Medium", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the field of blockchain technology, and in particular to a blockchain processing method, related apparatus and medium.

[0003] Background of the Invention

[0004] A block recorded on the blockchain contains one or more transactions. These transactions need to be executed before a block is added to the chain. After a transaction is executed, the state of the transaction objects associated with that transaction changes. For example, a traffic-related transaction might be "changing the traffic light at intersection A from red to green." The "traffic light at intersection A" is the transaction object, and its state changes from "red" to "green." Each transaction execution requires a corresponding change to the state of the recorded transaction objects. Each blockchain node in the network must maintain not only the blockchain itself but also the states of each transaction object. This leads to reduced resource utilization for each blockchain node. Furthermore, when new object state data needs to be recorded on a blockchain node, each node needs to perform a full storage of that object's state data, resulting in reduced storage efficiency. If not every blockchain node maintains full object state data, data security is difficult to guarantee. Summary of the Invention

[0005] This disclosure provides a blockchain processing method, related apparatus, and medium that can reduce the space occupation of the blockchain network and improve the resource utilization of the blockchain network while ensuring the security of object state data.

[0006] According to one aspect of this disclosure, a blockchain processing method is provided, executed by blockchain nodes in a blockchain network, the method comprising:

[0007] In response to a block on-chain request, an object state list is determined based on the state update data corresponding to at least one transaction object in the block. The object state list includes object state data of the at least one transaction object, and the object state data has a state data index for referring to the transaction object.

[0008] Based on the state data index, a full storage blockchain node for storing the object state data is determined in the blockchain network;

[0009] In response to the fact that the blockchain node is different from the full storage blockchain node, the object state data is sent to the full storage blockchain node so that the full storage blockchain node stores the object state data, the state data index and the storage sequence number accordingly, and the storage sequence number is used to indicate the storage order of the object state data in the full storage blockchain node;

[0010] Generate a first digest value for the object state data, and store the first digest value and the storage sequence number in the blockchain node;

[0011] Receive a query request for the object's status data, the query request containing the status data index;

[0012] Based on the state data index, a full storage blockchain node for storing the object state data is determined. The object state data and the storage sequence number are requested from the full storage blockchain node based on the state data index. The first digest value is queried in the blockchain node based on the storage sequence number, and the object state data is verified using the first digest value.

[0013] According to one aspect of this disclosure, a blockchain processing apparatus is provided, executed by a blockchain node in a blockchain network, the apparatus comprising:

[0014] An execution unit is configured to respond to a block's on-chain request and determine an object state list based on state update data corresponding to at least one transaction object in the block. The object state list includes object state data of the at least one transaction object, and the object state data has a state data index for referring to the transaction object.

[0015] A determining unit is configured to determine, based on the state data index, a full-scale storage blockchain node in the blockchain network for storing the object's state data.

[0016] A sending unit is configured to send the object state data to the full storage blockchain node in response to the fact that the blockchain node is different from the full storage blockchain node, so that the full storage blockchain node stores the object state data, the state data index and the storage sequence number accordingly, and the storage sequence number is used to indicate the storage order of the object state data in the full storage blockchain node;

[0017] A generation unit is used to generate a first digest value of the object state data and store the first digest value and the storage sequence number in the blockchain node.

[0018] A receiving unit is configured to receive a query request for the object's status data, the query request including the status data index;

[0019] The verification unit is configured to determine the full storage blockchain node for storing the object state data based on the state data index, request the object state data and the storage sequence number from the full storage blockchain node based on the state data index, query the first digest value in the blockchain node based on the storage sequence number, and verify the object state data using the first digest value.

[0020] According to one aspect of this disclosure, an electronic device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the blockchain processing method as described above.

[0021] According to one aspect of this disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program that, when executed by a processor, implements the blockchain processing method as described above.

[0022] According to one aspect of this disclosure, a computer program product is provided, the computer program product including a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the blockchain processing method as described above.

[0023] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings.

[0024] Brief description of the attached figures

[0025] The accompanying drawings are provided to further understand the technical solutions of this disclosure and constitute a part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0026] Figure 1 is a system architecture diagram of a blockchain processing method applied according to an embodiment of the present disclosure;

[0027] Figures 2A-2D illustrate schematic diagrams of the application of the blockchain processing method according to embodiments of the present disclosure in a state data storage scenario;

[0028] Figure 3 is a flowchart of a blockchain processing method according to an embodiment of the present disclosure;

[0029] Figure 4 is a flowchart of determining a full-scale storage blockchain node according to an embodiment of the present disclosure;

[0030] Figures 5A and 5B are schematic diagrams illustrating the implementation process of determining a full-scale storage blockchain node according to an embodiment of the present disclosure;

[0031] Figure 6 is a schematic diagram of the data structure of object state data during storage according to an embodiment of the present disclosure;

[0032] Figure 7 is a flowchart of stored object state data according to an embodiment of the present disclosure;

[0033] Figure 8 is a flowchart of generating a first digest value according to an embodiment of the present disclosure;

[0034] Figure 9 is a flowchart of generating a first digest value according to another embodiment of the present disclosure;

[0035] Figure 10 is a flowchart of verifying object state data according to an embodiment of the present disclosure;

[0036] Figure 11 is a schematic diagram of the implementation process of storing state data of each object according to an embodiment of the present disclosure;

[0037] Figure 12 is a flowchart of a full-scale storage blockchain node reliability verification according to an embodiment of the present disclosure;

[0038] Figure 13 is a flowchart of a full-scale storage blockchain node reliability verification according to another embodiment of the present disclosure;

[0039] Figure 14 is a flowchart of a full-scale storage blockchain node reliability verification according to another embodiment of the present disclosure;

[0040] Figure 15 is a schematic diagram illustrating the process of querying object status data according to an embodiment of the present disclosure;

[0041] Figure 16 is a flowchart of storage and querying when the blockchain node according to an embodiment of the present disclosure is a full-store blockchain node;

[0042] Figure 17 is a schematic diagram illustrating the implementation details of querying object state data in a blockchain processing method according to an embodiment of the present disclosure;

[0043] Figure 18 is a flowchart of updating a marker according to an embodiment of the present disclosure;

[0044] Figure 19 is a flowchart of verifying a first native integrator and a second native integrator according to an embodiment of the present disclosure;

[0045] Figures 20A-20E are schematic diagrams illustrating the implementation process of writing object state data according to an embodiment of the present disclosure;

[0046] Figure 21 is a schematic diagram illustrating the implementation details of writing object state data in a blockchain processing method according to an embodiment of the present disclosure;

[0047] Figure 22 is a block diagram of a blockchain processing apparatus according to an embodiment of the present disclosure;

[0048] Figure 23 is a terminal structure diagram of a blockchain processing method according to an embodiment of the present disclosure;

[0049] Figure 24 is a server structure diagram of a blockchain processing method according to an embodiment of the present disclosure.

[0050] Implementation

[0051] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0052] The system architecture and scenarios in which this disclosure is applied are described below.

[0053] Figure 1 is a system architecture diagram of the blockchain processing method applied according to an embodiment of the present disclosure. It includes an object terminal 140, an Internet 130, a gateway 120, a server 110, etc.

[0054] The object terminal 140 includes various forms such as desktop computers, laptops, personal digital assistants (PDAs), mobile phones, in-vehicle terminals, home theater terminals, and dedicated terminals. Furthermore, it can be a single device or a collection of multiple devices. The object terminal 140 can communicate with the Internet 130 via wired or wireless means to exchange data. The object terminal 140 includes a transaction processing platform, which provides the object with the means to submit transactions to be recorded on the blockchain.

[0055] Referring to server 110 in Figure 1, it includes a consensus network. A consensus network is a network that reaches a consensus on transactions to be added to the blockchain before adding them to the blockchain; it includes multiple consensus nodes. A consensus node is a blockchain node. A consensus node or blockchain node can be a server within a blockchain server or an object terminal connected to the blockchain server; the specific form of the consensus node or blockchain node is not limited here.

[0056] Gateway 120, also known as an internetwork connector or protocol converter, is a computer system or device that acts as a translator, enabling network interconnection at the transport layer. It bridges the gap between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateways can also provide filtering and security functions. Messages sent from target terminal 140 to server 110 are forwarded to the corresponding server 110 via gateway 120. Messages sent from server 110 to target terminal 140 are also forwarded to the corresponding target terminal 140 via gateway 120.

[0057] The embodiments disclosed herein can be applied to various scenarios, such as the state data storage scenarios shown in Figures 2A-2D.

[0058] As shown in Figure 2A, the blockchain network includes three blockchain nodes: blockchain node 1, blockchain node 2, and blockchain node 3. The blockchain node identifier for blockchain node 1 is N1, for blockchain node 2 it is N2, and for blockchain node 3 it is N3.

[0059] As shown in Figure 2B, each blockchain node in the blockchain network stores the complete content or summary content of the object state data of each transaction object. Specifically, blockchain node 1 records the historical state "red" and storage sequence number "1" corresponding to state index "TFL-013", the historical state "green" and storage sequence number "2" corresponding to state index "TFL-015", and a summary content "h3=ftq9861mr" with storage sequence number 3. Blockchain node 2 stores the summary content "h1=dafqafa" with storage sequence number 1, the summary content "h2=fqr16c" with storage sequence number 2, the historical state "good" and storage sequence number "3" corresponding to state index "Xx-K05", where summary content h1 is obtained by performing a summary operation on the object state data with storage sequence number 1 in blockchain node 1, and summary content h2 is obtained by performing a summary operation on the object state data with storage sequence number 2 in blockchain node 1. Blockchain node 2 stores digest content "h1 = dafqafa" (storage sequence number 1), digest content "h2 = fqr16c" (storage sequence number 2), and digest content "h3 = ftq9861mr" (storage sequence number 3). Digest content h3 is obtained by performing a digest operation on the object state data stored in blockchain node 2 at storage sequence number 3. At this point, the object state list has three transaction data items to be recorded in the blockchain sequentially. Transaction data 1 is "Change the traffic light at intersection A from red to green," its transaction object is "the traffic light at intersection A," its state index is "TFL-013," and its state is "green." Transaction data 2 is "Update the work performance of employee K of company Xx from good to excellent," its transaction object is "employee K of company Xx," its state index is "Xx-K05," and its state is "excellent." Transaction data 3 is "Set the maximum allowable noise level in area B to 60 dB", its transaction object is "maximum allowable noise level in area B", the status index of the transaction object is "ZS-B", and the object status is "60 dB".

[0060] Figure 2C illustrates the mapping relationship between blockchain node identifiers and transaction object state indices. The complete content of the transaction object's state data is recorded in the blockchain node pointed to by the blockchain node identifier corresponding to the transaction object's state index. Other blockchain nodes only record a summary of the transaction object's state data. Specifically, in the preset mapping table, the state indices of transaction objects corresponding to blockchain node identifier "N1" include "TFL-013," "TFL-015," etc.; the state indices of transaction objects corresponding to blockchain node identifier "N2" include "Xx-K05," "Xx-K11," etc.; and the state indices of transaction objects corresponding to blockchain node identifier "N3" include "ZS-B," "ZS-C," "ZS-D," etc.

[0061] As shown in Figure 2D, after recording the object state data corresponding to transaction data 1, transaction data 2, and transaction data 3 into the blockchain, the latest state of the object state data with storage sequence number 1 recorded in blockchain node 1 is "value: green". Correspondingly, the digest value of the object state data with storage sequence number 1 in blockchain nodes 2 and 3 becomes "h1=ra841mip". The latest state of the object state data with storage sequence number 3 recorded in blockchain node 2 is "value: excellent". Correspondingly, the digest value of the object state data with storage sequence number 3 in blockchain nodes 1 and 3 becomes "h3=yr57qfr". Simultaneously, a new state index "ZS-B" corresponding to storage sequence number 4 is recorded in blockchain node 3, and the state corresponding to state index "ZS-B" is "value: 60db". Correspondingly, a new digest content "h4=ftq9861mr" corresponding to storage sequence number 4 is added to both blockchain nodes 1 and 2.

[0062] The embodiments of this disclosure are described in general below.

[0063] According to one embodiment of this disclosure, a blockchain processing method is provided.

[0064] This blockchain processing method is generally applied in business scenarios where transaction processing generates a large amount of object state data that needs to be recorded on the blockchain, such as the state data storage scenarios shown in Figures 2A-2D. This disclosure provides a scheme for storing object state data based on a sharded storage method, which can reduce the space occupied by the blockchain network and improve the resource utilization of the blockchain network while ensuring the security of the object state data.

[0065] One embodiment of the blockchain processing method disclosed herein can be executed by a blockchain node in a blockchain network. The blockchain node can be any single blockchain node in the blockchain network.

[0066] As shown in Figure 3, a blockchain processing method according to an embodiment of this disclosure may include:

[0067] Step 310: In response to the block's on-chain request, determine the object state list based on the state update data in the block corresponding to at least one transaction object;

[0068] Step 320: Based on the state data index, determine the full storage blockchain node in the blockchain network used to store the object state data;

[0069] Step 330: In response to the fact that the blockchain node is different from the full storage blockchain node, send the object state data to the full storage blockchain node so that the full storage blockchain node stores the object state data, state data index and storage sequence number accordingly.

[0070] Step 340: Generate the first digest value of the object state data and store the first digest value and storage sequence number in the blockchain node;

[0071] Step 350: Receive a query request for object status data;

[0072] Step 360: Determine the full storage blockchain node for storing object state data based on the state data index, request object state data and storage sequence number from the full storage blockchain node based on the state data index, query the first digest value based on the storage sequence number in the blockchain node, and verify the object state data using the first digest value.

[0073] Steps 310-360 are described in detail below.

[0074] In step 310, in response to the block's on-chain request, an object state list is determined based on the state update data in the block corresponding to at least one transaction object.

[0075] A block refers to the block produced when it is the blockchain node's turn to act as the consensus master node. "Block production" here refers to the process by which the consensus master node packages the transactions to be confirmed into a new block and adds it to the blockchain.

[0076] An on-chain request refers to a request automatically triggered by the blockchain network when it reaches the point where a block needs to be recorded on the blockchain maintained by the blockchain network.

[0077] A block contains transaction data for at least one transaction object. The transaction data corresponding to a transaction object refers to the data packaged in the block and recorded on the blockchain. A transaction object is a logical unit in the blockchain that describes a specific business action; it contains all the necessary information to complete an operation. Transaction data is the actual content of the transaction object stored and recorded on the blockchain, that is, the data packaged into a block and permanently recorded on the chain.

[0078] The state update data of a transaction object refers to the write set data in the transaction data of the transaction object. The write set data often records the latest object state of the transaction object in the block.

[0079] The object state list is used to indicate the object state of each transaction object in the blockchain after the state update data of at least one transaction object has been confirmed as valid by each blockchain node in the blockchain network.

[0080] The object state list includes object state data for at least one transaction object, and the object state data for each transaction object has a state data index used to refer to that transaction object.

[0081] Object state data is used to indicate the latest state of a transaction object, provided that the transaction object's state update data is valid.

[0082] The status data index is used to identify transaction objects, distinguish the object status of a transaction object from that of other transaction objects, and clarify which transaction object the object status data belongs to.

[0083] For example, when considering students in a class as transaction objects, student IDs can be used as indexes for state data, and students' latest exam scores can be used as object state data.

[0084] When it's the blockchain node's turn to produce a block as the consensus master node, it responds to the block's on-chain request by first packaging multiple transaction data from its maintained transaction pool into a block. Based on the transaction data in the block, it generates read set data and write set data corresponding to each transaction object, recording these data in the block as well. The write set data directly reflects the latest state after transaction execution, while the read set data serves only as a snapshot before transaction execution and does not participate in state updates. Next, once the read and write set data for each transaction is generated, the transaction objects associated with each transaction's read and write set data will have a latest state, recorded in the write set data (state update data). Therefore, the blockchain node can integrate the latest states of transaction objects recorded in the write set data associated with each transaction into an object state list. In the object state list, the latest state of each transaction object and its state data index are bound together as a single object state data.

[0085] For example, a transaction in a block might be related to traffic, specifically the statement "change the traffic light at intersection A from red to green." The "traffic light at intersection A" is the transaction object, and its object identifier is traffic light004. Based on this transaction data, the write set data for the transaction object "traffic light at intersection A" is determined to be "green," and the read set data is determined to be "red." Therefore, the transaction object's state changes from "red" to "green." At this point, the status update data for the transaction object "traffic light at intersection A" is "green," and the object status data recorded in the object status data of the transaction object "traffic light at intersection A" is "green," with the status data index being traffic light004.

[0086] In a specific example, when it's the blockchain node's turn to produce a block, it first retrieves two transactions to be added to the blockchain, Transaction 1 and Transaction 2, from its own transaction pool. Transaction 1's data is "transfer 10 resources from resource pool A to resource pool B," and Transaction 2's data is "change the gate of area A from open to closed." Next, based on the transaction data of Transaction 1, the blockchain node retrieves the resource quantities from resource pool A and resource pool B within the blockchain network. It retrieves 100 resources from resource pool A and 50 resources from resource pool B. Simultaneously, based on the transaction data of Transaction 2, it retrieves the current state of the gate of area A as open. Based on this, the blockchain node generates read set data "Resource pool A has 100 resources; resource pool B has 50 resources" and write set data "Resource pool A has 90 resources; resource pool B has 60 resources" for the transaction data to be uploaded to the blockchain for transaction 1. It also generates read set data "The current state of the gate in area A is open" and write set data "The current state of the gate in area A is closed" for the transaction data to be uploaded to the blockchain for transaction 2. The node then records the transaction data and read / write set data for both transaction 1 and transaction 2 in the block. Further, the blockchain node uses the aforementioned write set data as the state update data for each transaction object and determines an object state list based on the state update data for each transaction object. This object state list records "The state data index of resource pool A is XX, and the object state data is 90," "The state data index of resource pool B is XXX, and the object state data is 60," and "The state data index of the gate in area A is XXXX, and the object state data is closed." In addition, the blockchain node will send the block to other blockchain nodes in the blockchain network. The other blockchain nodes will verify the block header information, block body information, etc., and generate a verification result indicating that the block verification is successful or unsuccessful. When the total number of blockchain nodes whose verification results indicate that the block verification is successful reaches more than two-thirds of the total number of blockchain nodes in the blockchain network, each blockchain node will record the block on the blockchain.

[0087] It should be noted that the blockchain node obtains the current state of the gate in area A, the resource counts of resource pool A and resource pool B from the full set of blockchain nodes used to store the object state data of each transaction object. This method of acquisition is similar to the process of querying the object state data of transaction objects in this embodiment. Furthermore, after determining the object state list containing the object state data of the aforementioned three transaction objects, the blockchain node stores the object state data of the transaction objects in a manner similar to the process described in this embodiment. For the sake of brevity, this will not be elaborated upon here.

[0088] Furthermore, when other blockchain nodes in the blockchain network verify the block header and block body information, they primarily verify the block height and previous block digest in the block header to ensure their correctness. They also verify the read / write data of each transaction object recorded in the block body information based on the object states of each transaction object obtained from the blockchain network and the changes in object states indicated by the transaction data. Only when both the block header and block body information are confirmed to be correct is the verification result considered passed, and the object state list is determined and stored based on the write set data of each transaction object in the block.

[0089] In step 320, based on the state data index, a full storage blockchain node for storing object state data is determined in the blockchain network.

[0090] A full-store blockchain node refers to a blockchain node in a blockchain network that stores the complete content of object state data locally.

[0091] Because there is a mapping relationship between transaction objects and each blockchain node for state data storage, a mapping relationship between the state data index of each transaction object and each blockchain node can be pre-constructed. This allows a transaction object's state data index to correspond to a specific blockchain node, and a single blockchain node to correspond to the state data indices of multiple transaction objects. Next, based on this mapping relationship, the blockchain node corresponding to the state data index is selected as the full storage blockchain node. Furthermore, after determining the object state list based on the state update data of each transaction object in the block, the blockchain node corresponding to the state data index is found through the pre-constructed mapping relationship, thus obtaining the full storage blockchain node used to store the object state data.

[0092] To save space, the specific implementation process of determining the full storage blockchain node corresponding to the stored object's state data based on the state data index in this disclosure embodiment will be described in detail below. It will not be repeated here.

[0093] In step 330, in response to the fact that the blockchain node is different from the full storage blockchain node, the object state data is sent to the full storage blockchain node so that the full storage blockchain node stores the object state data, the state data index and the storage sequence number accordingly.

[0094] The storage sequence number is used to indicate the storage order of object state data in the full storage blockchain node.

[0095] In response to the fact that this blockchain node is different from the full storage blockchain node, and it is determined that this blockchain node does not need to store the complete content of the object state data, the blockchain node will forward the object state data to the full storage blockchain node, so that the full storage blockchain node can determine the storage sequence number of the object state data, and store the object state data, state data index and storage sequence number accordingly, thereby realizing the storage of the complete content of the object state data in the blockchain.

[0096] It should be noted that when a full-scale storage blockchain node determines the storage sequence number of object state data, it first searches its local database based on the state data index. If the state data index exists in the local database, it indicates that the transaction object already has object state data stored in the full-scale storage blockchain node. In this case, the node directly searches the storage order of the state data index within the full-scale storage blockchain node to obtain the previously assigned storage sequence number. The newly received object state data then replaces the previously stored object state data, ensuring that the newly received object state data, the state data index, and the previously assigned storage sequence number are stored accordingly. If the state data index is not found in the local database, it indicates that the transaction object has not had object state data stored in the full-scale storage blockchain node. Therefore, the full-scale storage blockchain node assigns a new storage sequence number to the transaction object based on its storage order and stores the object state data, the state data index, and the newly assigned storage sequence number accordingly.

[0097] To save space, the specific implementation process of storing object state data, state data index, and storage sequence number in the full-scale storage blockchain node of this disclosure embodiment will be described in detail below. It will not be repeated here.

[0098] In step 340, a first digest value of the object state data is generated, and the first digest value is stored in the blockchain node along with the corresponding storage sequence number.

[0099] The first digest value refers to the result of a digest operation on the object's state data. The first digest value is a fixed-length string. It is used to indicate the object's state data in encrypted form.

[0100] Once a blockchain node stores the object state data, state data index, and storage sequence number, it can also determine the storage sequence number corresponding to the object state data. Based on this, the blockchain node can first perform a digest operation on the object state data to obtain a first digest value, and then store the first digest value and storage sequence number in its own maintained local database.

[0101] Furthermore, to enhance the security of the first digest value, when generating the first digest value, the blockchain node can first concatenate the object state data, state data index, and storage sequence number to obtain a concatenated result. Then, a digest operation is performed on the concatenated result to obtain the first digest value.

[0102] To save space, the specific implementation process of generating the first digest value of the object state data in this embodiment will be described in detail below. It will not be repeated here.

[0103] In step 350, a query request for object status data is received.

[0104] A query request is a request made to the blockchain network by a user to retrieve object state data from the blockchain. The query request includes a state data index.

[0105] When a user wants to retrieve object state data from the blockchain, the user sends a query request for the object state data to the blockchain network and provides the state data index corresponding to the object state data, so as to request the object state data to be found according to the state data index.

[0106] In step 360, a full storage blockchain node for storing object state data is determined based on the state data index. The object state data and storage sequence number are requested from the full storage blockchain node based on the state data index. The first digest value is queried in the blockchain node based on the storage sequence number, and the object state data is verified using the first digest value.

[0107] The specific process of determining the full storage blockchain node for storing object state data based on the state data index is similar to step 320 above.

[0108] Furthermore, once the full-store blockchain node corresponding to the object's state data is determined, that blockchain node sends the state data index to the full-store blockchain node and requests to retrieve the object's state data and storage sequence number corresponding to the state data index from the full-store blockchain node. Based on this, the full-store blockchain node, according to the state data index, the locally recorded object's state data, and the relationship between the state data index and the storage sequence number, finds the object's state data and storage sequence number corresponding to the state data index, and returns the object's state data and storage sequence number to the full-store blockchain node.

[0109] Furthermore, since dishonest full-store blockchain nodes may return incorrect object state data, when a blockchain node receives object state data and a storage sequence number, it can first look up the first digest value corresponding to that storage sequence number in its local database, based on the storage sequence number and the relationship between the storage sequence number and each first digest value recorded locally. Next, if the full-store blockchain node is honest, the found first digest value will indicate the object state data returned by the full-store blockchain node. Based on this, the blockchain node will use the first digest value to verify the object state data, perform a digest operation on the object state data to obtain a digest value, and compare this digest value with the first digest value. If the digest value matches the first digest value, it indicates that the object state data verification passed and the object state data is correct; this object state data is then fed back as the query result. If the digest value does not match the first digest value, it indicates that the object state data verification failed and the object state data provided by the full-store blockchain node is incorrect.

[0110] To save space, the specific implementation process of using the first digest value to verify the object state data in this embodiment will be described in detail below. It will not be repeated here.

[0111] Through steps 310-360 above, in this embodiment of the disclosure, not every blockchain node in the blockchain network maintains the full set of object state data. The full set of object state data refers to the complete, unedited, and unaggregated historical and current state data of a specific object (e.g., the state of a smart contract, the balance of an account, or the details of a document). For each object state data, only a subset of blockchain nodes are its full-scale storage blockchain nodes, storing its complete content. The remaining blockchain nodes only store its first digest value, thus significantly reducing the space occupied by the blockchain network and improving its resource utilization. Each object state data has a state data index that represents the transaction object, and its full-scale storage blockchain node can be determined based on this index. Simultaneously, a corresponding storage sequence number is assigned when storing object state data on a full-scale storage blockchain node. On non-full-scale storage blockchain nodes, the first digest value and storage sequence number of the object state data are stored correspondingly. When a query request is received, the full-store blockchain node storing the object's state data can be uniquely identified based on the state data index. The storage sequence number allows the determination of the object's state data's location within that full-store blockchain node. This ensures that even if a non-full-store blockchain node does not store the object's state data, it can still be obtained from the full-store blockchain node. Since the non-full-store blockchain node stores the first digest value, this value can be used to verify the obtained object's state data, thus ensuring its security. This embodiment of the present disclosure reduces the space occupied by the blockchain network and improves its resource utilization while ensuring the security of the object's state data.

[0112] The above is a general description of steps 310-360. Since steps 310 and 350 have been detailed in the above general description, the specific implementations of steps 320, 330, 340 and 360 will be described in detail below.

[0113] Step 320 will be described in detail below.

[0114] In step 320, based on the state data index, a full storage blockchain node for storing object state data is determined in the blockchain network.

[0115] In this embodiment of the disclosure, the blockchain network includes multiple blockchain nodes, each of which has a blockchain node identifier.

[0116] A blockchain node identifier is used to identify individual blockchain nodes and distinguish them from other blockchain nodes. The blockchain node identifier can be represented by numbers, letters, or a combination of numbers and letters.

[0117] In this embodiment, not every blockchain node in the blockchain network maintains the full set of object state data. For each object state data, only a subset of blockchain nodes are its full storage blockchain nodes, storing its complete content. The remaining blockchain nodes only store its first digest value, thus significantly reducing the space occupied by the blockchain network and improving its resource utilization. Each object state data has a state data index that represents a transaction object, and its full storage blockchain node can be determined based on this state data index. Simultaneously, a corresponding storage sequence number is assigned when storing object state data on a full storage blockchain node. On non-full storage blockchain nodes, the first digest value of the object state data and the storage sequence number are stored accordingly. When a query request is received, the full storage blockchain node storing the queried object state data can be uniquely determined based on the state data index, and the location of the object state data stored on that full storage blockchain node can be obtained based on the storage sequence number. Therefore, even if a non-full storage blockchain node does not store object state data, it is still possible to obtain the object state data from the full storage blockchain node. Because the non-full storage blockchain node stores the first digest value, the first digest value can be used to verify the obtained object state data, thereby ensuring the security of the object state data. This embodiment of the disclosure, while ensuring the security of the object state data, reduces the space occupied by the blockchain network and improves the resource utilization of the blockchain network.

[0118] Referring to Figure 4, in one embodiment, step 320 specifically includes, but is not limited to, the following steps 410-430:

[0119] Step 410: Perform a modulo operation between the state data index and the number of multiple blockchain nodes to obtain the remainder;

[0120] Step 420: Based on the remainder, determine the blockchain node identifier of the full storage blockchain node;

[0121] Step 430: Based on the blockchain node identifier, determine the full storage blockchain node.

[0122] Steps 410-430 are described in detail below.

[0123] In step 410, firstly, the state data index is converted into a byte array. The state data index is converted from integer form to binary form to obtain a byte, the size of which generally does not exceed 256. Next, a modulo operation is performed on this byte and the number of multiple blockchain nodes. The byte is divided by the number of multiple blockchain nodes to obtain the remainder.

[0124] In addition, when performing a modulo operation between the state data index and the number of multiple blockchain nodes, the state data index can be hashed using a hash function to convert it into a digest value. Then, the digest value is used to perform a modulo operation with the number of multiple blockchain nodes, and the remainder is obtained by dividing the digest value by the number of multiple blockchain nodes.

[0125] It should be noted that the number of multiple blockchain nodes refers to the total number of blockchain nodes in the blockchain network.

[0126] For example, a transaction within a block might be related to the annual performance evaluation grades of employees in a company. The transaction data might be "Employee ID 01246's annual performance evaluation grade is A," and "Employee ID 01246" is the transaction object, with its object identifier being 01246. After executing this transaction, the transaction object's state becomes "Annual performance evaluation grade is A." At this point, the object state data for the transaction object "Employee ID 01246" records the object state as "Annual performance evaluation grade is A," and the state data index could be 01246. Since each employee's employee ID is unique, the remainder obtained by performing a modulo operation between the employee ID and the number of blockchain nodes allows for a relatively even distribution of the company's employees' annual performance evaluation grades across the blockchain nodes for complete storage.

[0127] Furthermore, the status data index contains a status data class index, which indicates the category to which the transaction object belongs.

[0128] For example, a transaction within a block might be related to student exam scores at a school. The transaction data might be "Student kk in Class A scored 80 points on the exam," where "student kk in Class A" is the transaction object, and its object identifier is A-003, where A represents the class and 003 represents student kk's student ID. After updating the state of the transaction object (student kk in Class A) based on the transaction data, the transaction object's state becomes "score is 80 points." At this point, the object state data of the transaction object "student kk in Class A" records the object state as "score is 80 points," and the state data index could be A-003, where A is the state data class index.

[0129] In this embodiment, the remainder is obtained by performing a modulo operation between the state data index and the number of multiple blockchain nodes, including:

[0130] The remainder is obtained by performing a modulo operation between the state data index and the number of multiple blockchain nodes.

[0131] Specifically, the process of performing a modulo operation between the state data index and the number of multiple blockchain nodes is similar to the process described above.

[0132] For example, in a blockchain network containing blockchain node 1, blockchain node 2, and blockchain node 3, when the transaction is related to the exam scores of students in a school, if the transaction object is a student in class A, then the state data class index is A, and the exam scores are all recorded in blockchain node 1; if the transaction object is a student in class B, then the state data class index is B, and the exam scores are all recorded in blockchain node 2; if the transaction object is a student in class C, then the state data class index is C, and the exam scores are all recorded in blockchain node 3.

[0133] In step 420, since the modulo operation is based on the number of multiple blockchain nodes, the remainder is a positive integer no greater than the number of blockchain nodes. Based on this, before determining the full-store blockchain nodes, a one-to-one correspondence can be established between the remainder with different values ​​and the blockchain node identifiers. Thus, in the actual modulo operation, based on the specific value of the remainder and this correspondence, the blockchain node identifier corresponding to that specific value is found, and the found blockchain node identifier is determined as the blockchain node identifier of the full-store blockchain node.

[0134] In step 430, since the blockchain identifier of each blockchain node in the blockchain network is unique, the blockchain node possessing that blockchain identifier can be identified as the full storage blockchain node.

[0135] Figure 5A illustrates a general implementation process for determining a full-store blockchain node. Specifically, first, the state data index key is converted into a byte array; typically, the first byte is used as the key. At this point, the state data index key is converted into byte 0. Next, a modulo operation is performed using byte 0 and the total number of blockchain nodes to determine the full-store blockchain node corresponding to the state data index among blockchain node 1, blockchain node 2, blockchain node 3, and blockchain node 4. This ensures that the full-store blockchain node stores the complete content of the object state data with that state data index, while the non-full-store blockchain nodes store the digest value of the object state data with that state data index.

[0136] Figure 5B illustrates a specific implementation process for determining a full-store blockchain node. Specifically, first, the state data index key = Kb31 is converted into a byte array, resulting in byte 0 being 01101. Further, a modulo operation is performed using the total number of blockchain nodes (4), yielding a remainder of 2. Assuming this remainder perfectly matches the blockchain node identifier, the blockchain node with identifier 2 is located, and blockchain node 2 is determined as the full-store blockchain node for the object state data corresponding to state data index key = Kb31.

[0137] By adopting this embodiment, the mapping relationship between the remainder obtained by modulo operation on the state data index and the total number of blockchain nodes, and the blockchain node identifier, can effectively improve the convenience and accuracy of allocating full storage blockchain nodes for each object's state data (transaction object), making the storage of the complete content of each object's state data more balanced across blockchain nodes. Furthermore, a state data class index corresponding to the state data index is introduced, allowing the complete content of object state data belonging to the same major category of transaction objects to be stored in the same blockchain node. This improves the standardization of state data storage and the convenience of querying.

[0138] Step 330 will be described in detail below.

[0139] In step 330, in response to the fact that the blockchain node is different from the full storage blockchain node, the object state data is sent to the full storage blockchain node so that the full storage blockchain node stores the object state data, the state data index and the storage sequence number accordingly. The storage sequence number is used to indicate the storage order of the object state data in the full storage blockchain node.

[0140] In this embodiment of the disclosure, not every blockchain node in the blockchain network maintains the full set of object state data. For each object state data, only a subset of blockchain nodes are its full storage blockchain nodes, storing its complete content. The remaining blockchain nodes only store its first digest value. Since each object state data has a state data index, and there is a corresponding storage sequence number when storing object state data on a full storage blockchain node, the object state data, state data index, and storage sequence number are stored correspondingly on the full storage blockchain node. On the non-full storage blockchain node, the first digest value of the object state data and the storage sequence number are stored correspondingly. Based on this, this embodiment of the disclosure provides a data storage structure where each object state data is stored on both full storage blockchain nodes and non-full storage blockchain nodes.

[0141] As shown in Figure 6, in the data structure of the complete content of object state data stored in the full-storage blockchain node, each object state data is stored in the form of key-value pairs. The state data index (key) is used as the key, and the object state value, storage sequence number (index), and tag (next) are used together as the value corresponding to the state data index key. This tag indicates the storage sequence number of the adjacent object state data following the current object state data. Simultaneously, in the data structure of the first digest value of object state data stored in the non-full-storage blockchain node, the first digest value of each object state data is also stored in the form of key-value pairs. In this case, the storage sequence number and digest tag are used together as the key, and the result of the digest operation (first digest value) after concatenating the object state value, storage sequence number (index), and tag (next) is used as the value. The key is represented as h{$index}, where $index represents the number corresponding to the storage sequence number when it is in numerical form. The value is represented as hash(key:value:index:next).

[0142] For example, when the transaction object is "the traffic light at intersection A", the object state of the transaction object is "green", the state data index is 001, the storage sequence number is 3, and the storage sequence number of the tag "the traffic light at the next intersection of intersection A" is 4, the object state data of "the traffic light at intersection A" recorded by the non-full storage blockchain node is h{3} = hash(001:green:3:4).

[0143] Furthermore, since the object state data recorded by the non-full storage blockchain node is marked with the first digest value of each object state data according to the storage sequence number of the object state data, the non-full storage blockchain node cannot determine which state data indexes are stored in the index category of each state data index. Based on this, in this embodiment of the disclosure, in addition to recording the first digest value of each object state data, the non-full storage blockchain node also records the largest and smallest state data indexes in the state data indexes corresponding to the object state data already stored in the non-full storage blockchain node within the index category of each state data index.

[0144] Figure 6 shows the data structure for the range of stored state data indexes of other blockchain nodes stored by each blockchain node (not a full-store blockchain node). Specifically, each blockchain node stores the blockchain node identifier (NodeID) of other blockchain nodes, and records the range of state data corresponding to the complete content of the object state data stored in other blockchain nodes as "storage sequence number of the starting state data index - storage sequence number of the ending state data index" to correspond with the blockchain node identifier. For example, the range of state data indexes can be represented as:

[0145] start_key1[index]-end_key1[index]; start_key2[index]-end_key2[index].

[0146] Referring to Figure 7, in one embodiment, step 330 specifically includes, but is not limited to, the following steps 710-730:

[0147] Step 710: In response to the fact that the blockchain node is different from the full storage blockchain node, send the object state data to the full storage blockchain node;

[0148] Step 720: If the historical object state data corresponding to the state data index already stored on the full storage blockchain node is used, update the historical object state data with the object state data.

[0149] Step 730: If the historical object state data corresponding to the state data index is not stored on the full storage blockchain node, assign a storage sequence number to the object state data, and store the object state data, state data index and storage sequence number in the full storage blockchain node.

[0150] Steps 710-730 are described in detail below.

[0151] In step 710, if the blockchain node is not a full-storage blockchain node, it means that the blockchain node does not need to store the complete content of the object state data, and the blockchain node will forward the object state data to the full-storage blockchain node.

[0152] In step 720, historical object state data is used to indicate that, prior to the current time, the transaction object corresponding to the state data index has already had its object state data stored in the full-store blockchain node.

[0153] First, the full-store blockchain node searches its local database based on the state data index. If the state data index exists in the local database, it means that the transaction object already has object state data stored in the full-store blockchain node. Then, it retrieves the historical object state data corresponding to the state data index and updates the historical object state data with the object state data, so that the object state data, the existing state data index, and the storage sequence number are stored in a corresponding manner.

[0154] For example, the object status data with storage sequence number 1 in Figure 2. When the status data index of the object status data is "TFL-013", which points to the stored data with storage sequence number 1, and this status data index corresponds to a historical object status data "red", then the historical object status data "red" is directly replaced by the object status data "green" in transaction data 1.

[0155] In step 730, if the state data index is not found in the local database, it indicates that the transaction object has not stored object state data in the full-store blockchain node. At this time, the full-store blockchain node determines the last storage sequence number based on the storage sequence number corresponding to the complete content of the object state data already recorded in the local database and the storage sequence number corresponding to the first digest value of the object state data. It then increments this last storage sequence number by 1 to obtain the storage sequence number to be allocated to the object state data. Further, the full-store blockchain node stores the object state data, the state data index, and the newly allocated storage sequence number in a corresponding manner.

[0156] For example, in transaction 3 in Figure 2, since the state data index "ZS-B" has no stored historical object state data in the full storage blockchain node (blockchain node 3), and since blockchain node 3 has already recorded three data entries, the next data entry should be the fourth. Therefore, the storage sequence number of the object state data with the state data index "ZS-B" in transaction 4 is determined to be 4, and the state data index "ZS-B" and the object state data "60db" are stored corresponding to the storage sequence number "4".

[0157] This embodiment considers various scenarios where object state data is sent to full-scale storage blockchain nodes for storage. When historical object state data corresponding to a state data index exists in the full-scale storage blockchain node, the historical object state data is directly replaced with the new object state data, achieving rapid updates to the object state corresponding to the stored state data index while maintaining the unchanged storage sequence number. When no state data index exists in the full-scale storage blockchain node, the node assigns storage sequence numbers to the object state data based on the global situation of the stored object state data on the blockchain. This ensures that the storage sequence numbers clearly indicate the storage order in which each transaction object generates object state data on the blockchain. This reduces the space occupied by the blockchain network, improves the resource utilization of the blockchain network, and enhances the storage standardization and orderliness of object state data.

[0158] Step 340 will be described in detail below.

[0159] In step 340, a first digest value of the object state data is generated, and the first digest value is stored in the blockchain node along with the corresponding storage sequence number.

[0160] Referring to Figure 8, in one embodiment, step 340 specifically includes, but is not limited to, the following steps 810-820:

[0161] Step 810: If the blockchain node already stores the second digest value of the historical object state data corresponding to the state data index, then generate the first digest value and update the second digest value with the first digest value;

[0162] Step 820: If the second digest value of the historical object state data corresponding to the state data index is not stored on the blockchain node, then generate the first digest value and store the first digest value and the storage sequence number on the blockchain node.

[0163] Steps 810-820 are described in detail below.

[0164] In step 810, the second digest value is used to indicate the result of the digest operation performed by the blockchain node on the historical object state data.

[0165] When a full-storage blockchain node is an honest node, after storing the object state data, state data index, and storage sequence number, the full-storage blockchain node provides the storage sequence number corresponding to the state data index to itself. Based on this, the blockchain node has the opportunity to find a stored data record corresponding to the storage sequence number provided by the full-storage blockchain node when searching in its local database. Furthermore, when a stored data record corresponding to the storage sequence number is found in the local database, this stored data should be the second digest value of the historical object state data corresponding to the state data index. Next, the blockchain node concatenates the object state data, state data index, and storage sequence number returned by the full-storage blockchain node into a string, then performs a digest operation on this string to obtain the first digest value. Finally, the first digest value replaces the second digest value for storage. The aforementioned digest operation on the string can refer to applying a specific cryptographic hash function. This hash function can map input data of arbitrary length to a fixed-length, unique output value, i.e., the first digest value. This computation process is input-sensitive, meaning that even a small change in the input data will cause a significant and unpredictable change in the generated digest value. In this way, any unauthorized tampering with the original data (including object state data, state data index, and storage sequence number) will cause the stored first digest value to differ from the recalculated result, thus being detected by the system.

[0166] For example, in Figure 2, the state data index "TFL-013" in blockchain node 2 stores a digest value h1, where the digest value h1 = dafqafa. This digest value is calculated based on the storage sequence number 1, the state data index TFL-013, and the historical object state data "red". When recording transaction 1, blockchain node 2 will recalculate the digest based on the storage sequence number 1, the state data index TFL-013, and the object state data "green", resulting in a digest value "ra841mip". The digest value h1 corresponding to the storage sequence number will then be updated from "dafqafa" to "ra841mip".

[0167] In step 820, when the blockchain node does not find a record of stored data corresponding to the storage sequence number in its local database, it can be assumed that the blockchain node does not store the second digest value of the historical object state data corresponding to the state data index, indicating that the blockchain node has not yet recorded the digest information of the object state data related to the state data index. For this blockchain node, the object state data represents the object state data of a newly added transaction object. Based on this, the blockchain node first concatenates the object state data, the state data index, and the storage sequence number returned by the full-store blockchain node into a string, then performs a digest operation on this string to obtain the first digest value. Finally, the first digest value is stored in its own maintained local database, corresponding to the storage sequence number.

[0168] For example, in transaction 3 in Figure 2, since the state data index "ZS-B" has no stored digest content in the non-full storage blockchain node (blockchain node 2), and since blockchain node 2 has already recorded three data entries, the next data entry should be the fourth. Therefore, the storage sequence number of the object state data with the state data index "ZS-B" in transaction 4 is determined to be 4. The state data index "ZS-B" and the object state data "60db" are used together with the storage sequence number "4" to calculate the digest, resulting in a digest result "ftq9861mr". The digest value h4 corresponding to the storage sequence number "4" is then recorded as "ftq9861mr".

[0169] It should be noted that, considering the possibility that a full-store blockchain node might be dishonest, providing an incorrect storage sequence number or not providing one at all, the blockchain node cannot know whether its local database has stored the first digest value corresponding to the state data index. To address this, this disclosure provides a scheme where the full-store blockchain node provides object state data corresponding to other state data indices adjacent to the current state data index, and introduces a verification mechanism. This scheme allows the blockchain node to determine the storage sequence number corresponding to the state data index. This scheme is similar to the specific process described later where the blockchain node determines the storage sequence number when updating the tags corresponding to already stored object state data.

[0170] This embodiment addresses various scenarios where non-full-store blockchain nodes convert object state data into digest values ​​for storage. When a second digest value for historical object state data corresponding to a state data index exists in the non-full-store blockchain node, the second digest value is directly replaced with the first digest value. This enables rapid updating of the digest value corresponding to the stored state data index while maintaining the unchanged storage sequence number. Conversely, when no state data index exists in the non-full-store blockchain node, the node generates a first digest value based on the object state data, the state data index, and the storage sequence number provided by the full-store blockchain node. This improves the accuracy of the first digest value generation and associates it with the storage sequence number. This approach reduces the blockchain network's space footprint, improves resource utilization, and enhances the accuracy and orderliness of the first digest values ​​for each object's state data.

[0171] Referring to Figure 9, in one embodiment, step 810 specifically includes, but is not limited to, the following steps 910-930:

[0172] Step 910: If the second digest value of the historical object state data corresponding to the state data index has been stored on the blockchain node, then obtain the historical object state data corresponding to the state data index from the full storage blockchain node.

[0173] Step 920: Perform a digest operation on the historical object state data to obtain the third digest value;

[0174] Step 930: If the second digest value is consistent with the third digest value, then generate the first digest value and update the second digest value with the first digest value.

[0175] Steps 910-930 are described in detail below.

[0176] In step 910, since the storage sequence number, state data index, and other data provided by the full-store blockchain node may contain errors, it is necessary to verify the relevant data provided by the full-store blockchain node to reduce the risk of incorrectly modifying the first digest value stored locally by the blockchain node. Specifically, if the blockchain node already stores the second digest value of the historical object state data corresponding to the state data index, the blockchain node will also obtain the historical object state data corresponding to the state data index from the full-store blockchain node, so that the full-store blockchain node will send the historical object state data corresponding to the state data index and the storage sequence number to the full-store blockchain node.

[0177] In step 920, the third digest value refers to the result of the digest operation performed by the blockchain node based on the historical object state data corresponding to the state data index provided by the full storage blockchain node.

[0178] The blockchain node will perform a digest operation on the historical object state data in the same way as it did in generating the second digest value, to obtain the third digest value.

[0179] For example, if the second digest value is generated by the blockchain node through digest operation based on the state data index and the previously received historical object state data, then the blockchain node will also perform digest operation on the historical object state data provided by the full storage blockchain node and the state data index to generate the third digest value.

[0180] In step 930, if the second digest value matches the third digest value, it indicates that the historical object state data and storage sequence number provided by the full-store blockchain node correspond to the state data index. Based on this, the blockchain node will generate a first digest value and then replace the second digest value with the first digest value for storage. However, if the second digest value does not match the third digest value, it indicates that the historical object state data and storage sequence number provided by the full-store blockchain node do not correspond to the state data index. The full-store blockchain node has engaged in dishonest behavior. Therefore, after penalizing the full-store blockchain node, it can be required to re-provide the historical object state data and storage sequence number corresponding to the state data index.

[0181] For example, in Figure 2, blockchain node 2 contains a digest value h2 corresponding to the state data index "TFL-015". When the storage sequence number corresponding to the state data index TFL-015 provided by blockchain node 1 is 2, and the object state data is "red", blockchain node 2 will perform digest calculation based on the storage sequence number "2", the state data index "TFL-015", and the object state data "red", obtaining a digest result. However, this digest result will be inconsistent with the digest value h2. This is because the object state data recorded by blockchain node 2 is actually green, but the object state data provided by blockchain node 1 is red.

[0182] By adopting this embodiment, when the blockchain node stores the first digest value corresponding to the object state data, it takes into account the verification of relevant data such as the storage sequence number provided by the full-store blockchain node. Based on the historical object state data, storage sequence number, and state data index provided by the full-store blockchain node, the digest is recalculated to obtain a third digest value. The third digest value is compared with the locally stored second digest value. This can realize the verification of the storage sequence number provided by the full-store blockchain node, thereby reducing the risk of erroneous modification of the second digest value stored locally by the blockchain node and improving the storage accuracy of the first digest value corresponding to the object state data.

[0183] Step 360 will be described in detail below.

[0184] In step 360, a full storage blockchain node for storing object state data is determined based on the state data index. The object state data and storage sequence number are requested from the full storage blockchain node based on the state data index. The first digest value is queried in the blockchain node based on the storage sequence number, and the object state data is verified using the first digest value.

[0185] Since the storage sequence number can uniquely identify the storage order and storage location of each object's state data on the blockchain, this disclosure provides a scheme that tightly binds the object's state data with the storage sequence number when storing each object's state data, which can improve the convenience of querying the complete content or first digest value of the object's state data based on the storage sequence number.

[0186] In one embodiment, step 340 includes:

[0187] The object state data and storage sequence number are combined, for example, by cascading, to obtain the original data, which is referred to as the native integrated body below;

[0188] Perform a digest operation on the native integrator to obtain the first digest value.

[0189] The native integrated entity refers to a data structure formed by the object's state data and its storage sequence number.

[0190] Since the object state data has a state data index, the native integrated body of this embodiment can also be regarded as a data body formed by the three elements of object state data, state data index and storage sequence number.

[0191] Specifically, first, a triplet template is constructed, containing a first field with an empty value, a second field with an empty value, and a third field with an empty value. The first field stores the state data index, the second field stores the object state data, and the third field stores the storage sequence number. Next, for each object state data, the blockchain node fills the second field with transaction state data, the first field with the state data index, and the third field with the storage sequence number, thus forming the native aggregate. Finally, the blockchain node performs a digest operation on the native aggregate to obtain the first digest value.

[0192] For example, the transaction object with the status data index "TFL-013" in Figure 2 has the original consolidation body "key=TFL-013, value=green, index=1".

[0193] Please refer to Figure 10. In this embodiment, step 360 specifically includes, but is not limited to, the following steps 1010-1040:

[0194] Step 1010: Receive object state data and storage sequence number from the full-scale storage blockchain node;

[0195] Step 1020: Combine the received object status data with the storage sequence number, for example, by cascading, to obtain combined data, hereinafter referred to as the regenerated integrator;

[0196] Step 1030: Perform a summary operation on the regenerated integrand to obtain the fourth summary value;

[0197] Step 1040: Verify the object state data based on the first digest value and the fourth digest value.

[0198] Steps 1010-1040 are described in detail below.

[0199] In step 1010, after requesting object state data and storage sequence number from the full-storage blockchain node based on the state data index, the full-storage blockchain node searches its local database for the corresponding object state data and storage sequence number based on the state data index sent by the blockchain node, and returns the found object state data and storage sequence number to the blockchain node. Based on this, the blockchain node can receive object state data and storage sequence number from the full-storage blockchain node.

[0200] In step 1020, the regenerated integrator is used to instruct the blockchain node to form a data structure by concatenating the object state data and storage sequence number received from the full storage blockchain node.

[0201] The specific process of step 1020 is similar to the specific process of integrating the object state data and storage sequence number in step 340 above to obtain the native integrated body.

[0202] In step 1030, the fourth digest value is the result of the digest operation performed by the blockchain node on the regenerated consolidation.

[0203] The specific process of step 1030 is similar to the specific process of performing a digest operation on the native integrator to obtain the first digest value in step 340 above.

[0204] In step 1040, if the full-storage blockchain node is an honest node, then the regenerated integrator constructed based on the object state data, storage sequence number, and state data index returned by the full-storage blockchain node is completely consistent with the original integrator, and the results of the digest operation (first digest value and fourth digest value) will also be consistent. Based on this, the first digest value and the fourth digest value are compared first. Next, if the first digest value and the fourth digest value are inconsistent, it indicates that the data content of the regenerated integrator and the original integrator are inconsistent, and the object state data and storage sequence number returned by the full-storage blockchain node may be incorrect. Therefore, the blockchain node will determine that the object state data verification fails and request the full-storage blockchain node to return correct object state data. When the first digest value and the fourth digest value are consistent, it indicates that the object state data returned by the full-storage blockchain node is correct, the object state data verification is successful, and the object state data is fed back as the query result.

[0205] By adopting this embodiment, when storing the state data of each object, the object state data is tightly bound to the storage sequence number. In the full-storage blockchain node, the object state data, state data index, and storage sequence number are constructed into a native integrated body, and the native integrated body is stored correspondingly to the storage sequence number. On the non-full-storage blockchain node, the first digest value generated by digesting the original integrated body is bound to the storage sequence number and stored. This improves the convenience of querying the complete content of the object state data or the first digest value based on the storage sequence number. Furthermore, when verifying the object state data provided by the full-storage blockchain node during the query, the object state data and storage sequence number are also integrated into a regenerated integrated body, and the fourth digest value of the regenerated integrated body is compared with the first digest value. This improves the accuracy of object state data verification and reduces the risk of fraud in providing object state data by the full-storage blockchain node.

[0206] The following describes in detail another embodiment of the present disclosure the specific process of storing and querying object state data.

[0207] Because using only storage sequence numbers to identify the complete content or first digest value of each object's state data stored on the blockchain can lead to inaccurate verification of the correctness of the object state data provided by the full-store blockchain node during the query phase. For example, when querying the object state data corresponding to a certain state data index, the full-store blockchain node might directly state that there is no object state data corresponding to that index, making verification impossible. Alternatively, the full-store blockchain node could provide incorrect storage sequence numbers and incorrect object state data, resulting in the incorrect sequence numbers and data being stored together. In this case, the first digest value extracted by the blockchain node based on the storage sequence number would also be generated from incorrect object state data. Although this first digest value does not correspond to the state data index, the final verification will still pass. For example, if the query is for the object state data corresponding to state data index A, and the full-store blockchain node provides the object state data and storage sequence number for state data index B, then the blockchain node will find the first digest value of state data index B in its local storage based on the storage sequence number. This verifies that the object state data for state data index B can be successfully verified. Therefore, the blockchain node will return the object state data for state data index B as if it were the object state data for state data index A. Based on this, this disclosure provides an object state data storage scheme that identifies the dependency relationship between various state data indices using tags. This improves the rationality of object state data storage and the accuracy of queries, and reduces the risk of cheating by the full-store blockchain node during the query phase.

[0208] It should be noted that in this embodiment of the disclosure, the marker is the storage sequence number of the adjacent object state data (already stored in the blockchain) whose state data index follows the object state data. If there is no adjacent object state data whose state data index follows the object state data, the marker is a first value.

[0209] Figure 11 illustrates how, in one embodiment of this disclosure, the complete content and first digest value of each object's state data are stored in the blockchain after the introduction of this marker. Specifically, the storage rule is as follows: the full blockchain node corresponding to class index a of the state data index is blockchain node 1; the full blockchain node corresponding to class index b of the state data index is blockchain node 2; the full blockchain node corresponding to class index c of the state data index is blockchain node 3; and the full blockchain node corresponding to class index d of the state data index is blockchain node 4. When recording the object state list of a transaction object with five transaction data associations on the blockchain, the object state data corresponding to each transaction data is written into the blockchain sequentially according to the execution order. The five transaction data are: Transaction 1, associated with object state data of object state va1 (state data index a1); Transaction 2, associated with object state data of object state va4 (state data index a4); Transaction 3, associated with object state data of object state vb1 (state data index b1); Transaction 4, associated with object state data of object state vc1 (state data index c1); and Transaction 5, associated with object state data of object state vd1 (state data index d1). When writing the object state data associated with each transaction data, the object state data, storage sequence number, tag, and state data index are bound and stored together.

[0210] Furthermore, in blockchain node 1, the first recorded item is object state data va1 with storage sequence number 1, tag number 2, and state data index a1. The second recorded item is object state data va4 with storage sequence number 2, tag number 0, and state data index a4. The third recorded item is a first digest value h3 with storage sequence number 3, which corresponds to object state data with state data index b1 and is obtained based on that object state data, its state data index, storage sequence number, and tag. The fourth recorded item is a first digest value h4 with storage sequence number 4, which corresponds to object state data with state data index c1. The fifth recorded item is a first digest value h5 with storage sequence number 5, which corresponds to object state data with state data index d1. In addition, blockchain node 1 also records the state data index of the object state data with complete content stored in blockchain node 2, which is b1[3]-b1[3]; the state data index of the object state data with complete content stored in blockchain node 3 is c1[4]-c1[4]; and the state data index of the object state data with complete content stored in blockchain node 4 is d1[5]-d1[5].

[0211] Furthermore, in blockchain node 2, the first recorded value is a first digest value h1 with storage sequence number 1, which corresponds to the object state data with state data index a1. The second recorded value is a first digest value h2 with storage sequence number 2, which corresponds to the object state data with state data index a4. The third recorded value is object state data vb1 with storage sequence number 3, marked as 0, and state data index b1. The fourth recorded value is a first digest value h4 with storage sequence number 4, which corresponds to the object state data with state data index c1. The fifth recorded value is a first digest value h5 with storage sequence number 5, which corresponds to the object state data with state data index d1. In addition, blockchain node 1 also records the state data index of the object state data with complete content stored in blockchain node 2, which is b1[3]-b1[3]; the state data index of the transaction state data with complete content stored in blockchain node 3 is c1[4]-c1[4]; and the state data index of the object state data with complete content stored in blockchain node 4 is d1[5]-d1[5].

[0212] Furthermore, the storage method of the object state data recorded by blockchain nodes 3 and 4 is similar to that of blockchain nodes 1 and 2.

[0213] In one embodiment, step 320 specifically includes:

[0214] In response to the fact that the blockchain node is different from the full storage blockchain node, the object state data is sent to the full storage blockchain node so that the full storage blockchain node can concatenate the object state data, storage sequence number and tag to obtain the original data of the object state data, that is, the original integrated body, and store the original integrated body.

[0215] The marker is the storage sequence number of the second adjacent object state data after the object state data in the state data index. If there is no second adjacent object state data after the object state data in the state data index, the marker is the first value.

[0216] It should be noted that the first value is a special numerical value or a letter that distinguishes it from the stored sequence number. For example, when the stored sequence numbers are integers that increment from 1, the first value can be set to 0.

[0217] The specific process of sending object state data to the full storage blockchain node is similar to step 710 above. Further, after the full storage blockchain node receives the object state data, it extracts the state data index from the object state data and combines the object state data, storage sequence number, and the tag. For example, it concatenates the object state data, storage sequence number, and the tag to obtain the original object state data, i.e., the native integrated body. Finally, it stores the native integrated body. The specific process of combining the object state data, storage sequence number, and the tag to obtain the native integrated body of the object state data is similar to the specific process in step 340 above where the blockchain node combines the object state data and storage sequence number to obtain the native integrated body.

[0218] Furthermore, the storage form of the native integrated entity composed of object state data, storage sequence number and tag concatenated in this embodiment on the full storage blockchain node is basically the same as the data structure of the complete content of object state data stored on the full storage blockchain node described in Figure 6 above, and will not be repeated here.

[0219] For example, when storing transaction 1 with state data index a1 and object state data va1 in Figure 11, blockchain node 1 is a full storage blockchain node. Since no other transaction object's object state data has been stored before transaction 1, the storage sequence number of the object state data with state data index a1 is set to 1. Furthermore, since transaction 2 with state data index a4 and object state data va4 is stored after transaction 1 with state data index a1 and object state data va1 in Figure 11, the storage sequence number of the object state data with state data index a4 is set to 2. Also, since the object state data with state data index a4 is the closest to state data index a1 after the object state data with state data index a1, and there are no other object state data with state data index a4 starting with 'a', the marker for the object state data with state data index a1 is recorded as the storage sequence number 2 corresponding to state data index a4. The marker for the object state data with state data index a4 is recorded as 0. Specifically, the state data (native integrated body) of the transaction object with state data index a1 is stored as "a1-[va1,index:1,next:2]"; the state data (native integrated body) of the object with state data index a4 is stored as "a4-[va4,index:2,next:0]".

[0220] In this embodiment, step 340 specifically includes:

[0221] The native consolidation is obtained from the full-scale storage blockchain node, and a digest operation is performed on the native consolidation to obtain the first digest value.

[0222] Specifically, since all the data of the native integrator is known after the full-store blockchain node stores it, it can request the native integrator from the full-store blockchain node. Upon receiving the request, the full-store blockchain node returns its local native integrator. Then, the blockchain node performs a digest operation on the raw data obtained from the full-store blockchain node—the native integrator—to obtain the first digest value.

[0223] By adopting this embodiment, when storing object state data, based on the dependency relationship of each state data index, the storage sequence number of the nearest object state data after the object state data is marked, which can improve the rationality of object state data storage and query accuracy, and reduce the risk of full-store blockchain nodes cheating during the query phase.

[0224] When a node in the full-store blockchain is dishonest, during the query phase, it may respond with "no data found" or provide incorrect object state data even though it locally stores the object state data corresponding to the state data index. This prevents normal querying of object state data on the blockchain, affecting the accuracy of data queries. Therefore, this disclosure provides a scheme for verifying the object state data provided by the full-store blockchain during the query phase based on tags, which can improve query accuracy and reliability.

[0225] When the blockchain node finds a native integrator with a corresponding tag in the full-store blockchain node based on the state data index, the blockchain node retrieves the native integrator from the full-store blockchain node, re-concatenates the object state data, tag, storage sequence number, and state data index in the native integrator, performs a digest operation to obtain a digest result, and compares the digest result with the first digest value found in the local database based on the storage sequence number, thereby verifying the object state data in the native integrator. The specific process of comparing the digest result with the first digest value and verifying the object state data in the native integrator in this embodiment is similar to steps 1010-1040 above. The difference is that the native integrator in this embodiment has an additional tag compared to the native integrator in steps 1010-1040 above.

[0226] For example, after storing the object state data associated with the five transactions in the object state list in Figure 11 into the blockchain, blockchain node 2 receives a query request for the object state data with state data index a1. Based on this, blockchain node 2 sends the state data index a1 to blockchain node 1 and requests blockchain node 1 to provide the original integrator corresponding to state data index a1. At this time, blockchain node 1 returns [a1, va1, index: 1, next2] to blockchain node 2. Further, blockchain node 2 reconstructs a regenerated integrator based on these four parameters (a1, va1, index: 1, next2) and performs a digest operation on the regenerated integrator to obtain a digest value. Then, it extracts a first digest value (h1) corresponding to storage sequence number 1 from the local database. If the first digest value matches the calculated digest value, the object state data va1 in the original integrator is fed back as the query result. If the first digest value does not match the calculated digest value, blockchain node 1 can be requested to provide the correct object state data again.

[0227] Referring to Figure 12, in one embodiment, after requesting object state data and storage sequence number from the full-store blockchain node based on the state data index, the blockchain processing method further includes, but is not limited to, the following steps 1210-1220:

[0228] Step 1210: If object state data and storage sequence number are not received from the full storage blockchain node, request the first original data of the first adjacent object state data (hereinafter referred to as the first native integrator) and the second original data of the second adjacent object state data (hereinafter referred to as the second native integrator) from the full storage blockchain node.

[0229] Step 1220: Based on the first native integration and the second native integration, perform reliability verification on the full-scale storage blockchain nodes.

[0230] Steps 1210-1220 are described in detail below.

[0231] In step 1210, the state data index of the first adjacent object state data is placed before the state data index corresponding to the object state data, and the state data index of the second adjacent object state data is placed after the state data index corresponding to the object state data.

[0232] The complete contents of the state data of the first adjacent object and the state data of the second adjacent object have been stored on the full-storage blockchain node, and the first digest values ​​of the state data of the first adjacent object and the state data of the second adjacent object have also been stored on the non-full-storage blockchain node.

[0233] It should be explained that the first adjacent object state data is not all stored object state data whose state data index precedes the corresponding state data index of the object state data. Rather, it is the stored object state data whose state data index precedes the corresponding state data index of the object state data, and whose corresponding state data index is closest in position to the state data index of the object state data. Similarly, the second adjacent object state data is not all stored object state data whose state data index follows the corresponding state data index of the object state data. Rather, it is the stored object state data whose state data index follows the corresponding state data index of the object state data, and whose corresponding state data index is closest in position to the state data index of the object state data.

[0234] If no object state data and storage sequence number are received from the full-store blockchain node, it indicates that the full-store blockchain node does not store the object state data corresponding to that state data index. In this case, there are two possibilities: first, the full-store blockchain node genuinely does not store the object state data corresponding to that state data index; second, the full-store blockchain node actually stores the object state data corresponding to that state data index, but is cheating by claiming it does not. Based on this, the blockchain node needs to verify whether the full-store blockchain node has engaged in cheating. Therefore, the blockchain node will continue to request the full-store blockchain node to return the first native concatenation of the first adjacent object state data and the second native concatenation of the second adjacent object state data. At this point, the full-store blockchain node, based on the request, will search its local database for the object state data corresponding to the state data index that is closest in position to the current state data index, designated as the first adjacent object state data. It will then search for the object state data corresponding to the state data index that is closest in position to the current state data index, designated as the second adjacent object state data. Next, it will return the first native concatenation of the first adjacent object state data and the second native concatenation of the second adjacent object state data to the blockchain node.

[0235] For example, in Figure 11 above, when querying object state data with state data index a2, the full-store blockchain node will provide the native concatenation with state data index a1 as the first native concatenation of the first adjacent object state data, and provide the native concatenation with state data index a4 as the second native concatenation of the second adjacent object state data. Specifically, assuming the query is for object state data with state data index a5, the full-store blockchain node will only provide the native concatenation with state data index a4 as the first native concatenation of the first adjacent object state data, and will not provide the second native concatenation.

[0236] In step 1220, when performing reliability verification on the full-scale storage blockchain node based on the first native integrated body and the second native integrated body, the correctness of the specific data content of the first native integrated body and the second native integrated body can be verified, and the relationship between the first native integrated body and the second native integrated body can be verified, thereby realizing reliability verification of the full-scale storage blockchain node in multiple dimensions.

[0237] To save space, the specific process of reliability verification of the full-scale storage blockchain nodes based on the first native integrated entity and the second native integrated entity in this embodiment will be described in detail below. It will not be repeated here.

[0238] By adopting this embodiment, considering the possibility that when the full storage blockchain node does not receive object state data and storage sequence number, the full storage blockchain node may actually store the object state data corresponding to the state data index, but claim that it does not store the object state data corresponding to the state data index, thus engaging in cheating behavior. The blockchain node continues to request the first and second native integrators from the full storage blockchain node, and performs reliability verification on the full storage blockchain node based on the first and second native integrators. This reduces the cheating risk of the full storage blockchain node and improves the accuracy of object state data query.

[0239] Referring to Figure 13, in one embodiment, step 1220 specifically includes, but is not limited to, the following steps 1310-1330:

[0240] Step 1310: If the first native concatenation and the second native concatenation are received from the full storage blockchain node, and the tag in the first native concatenation is equal to the storage sequence number in the second native concatenation, then the reliability verification is confirmed to be successful.

[0241] Step 1320: If only the first native consolidation is received from the full storage blockchain node, and the marker in the first native consolidation is the first value, then the reliability verification is confirmed to be successful.

[0242] Step 1330: If only the second native consolidation is received from the full storage blockchain node, and the object state data is determined based on the index list to be the object state data with the smallest state data index in the object state data block, then the reliability verification is deemed successful.

[0243] Steps 1310-1330 are described in detail below.

[0244] In step 1310, if no object state data and storage sequence number are received from the full-scale storage blockchain node, it indicates that the state data indexes of the first and second native integrators stored on the blockchain should be adjacent, and the marker in the first native integrator should point to the storage sequence number of the second native integrator. Based on this, if the first and second native integrators are received from the full-scale storage blockchain node, the marker of the first native integrator is compared with the storage sequence number of the second native integrator. If the marker in the first native integrator equals the storage sequence number in the second native integrator, it indicates that the full-scale storage blockchain node has returned unstored object state data and storage sequence number. Not providing object state data and storage sequence number is normal behavior. Therefore, the full-scale storage blockchain node verification is successful, and it can reply to the initiator of the query request that no corresponding object state data was found. If the marker in the first native integrator is not equal to the storage sequence number in the second native integrator, it indicates that the state data index of the first native integrator and the state data index of the second native integrator stored on the blockchain are not directly adjacent. The full storage blockchain node should also store object state data whose state data index is located between the state data index of the first native integrator and the state data index of the second native integrator. Therefore, the full storage blockchain node's failure to provide object state data and storage sequence number is cheating, and the reliability verification of the full storage blockchain node is determined to be unsuccessful. The blockchain node can also request the full storage blockchain node to return the object state data again.

[0245] In step 1320, if only the first native consolidation is received from the full-store blockchain node, then there is no state data index in the state data index stored on the full-store blockchain node that follows the state data index of the object state data to be queried. The state data index in the first native consolidation is the largest state data index in the state data index stored on the full-store blockchain node that precedes the state data index of the object state data to be queried. Therefore, the full-store blockchain node does not store any object state data whose state data index follows the first native consolidation, and the marker in the first native consolidation should be the first value. Based on this, if only the first native consolidation is received from the full-store blockchain node, and the marker in the first native consolidation is the first value, it indicates that the full-store blockchain node is an honest node, and the reliability verification is confirmed to be successful. If the full-store blockchain node only receives the first native concatenation, but the marker in the first native concatenation is not the first value, it indicates that there is object state data on the full-store blockchain node whose state data index ranks after the first native concatenation. The first native concatenation is not necessarily the object state data whose state data index ranks before the object state data being queried, nor is it necessarily the object state data whose state data index is closest to the object state data. This indicates that the full-store blockchain node has acted dishonestly, and the relevant data it returned based on the request is incorrect. Therefore, the reliability verification of the full-store blockchain node is determined to have failed. This blockchain node can also request the full-store blockchain node to return the object state data again.

[0246] In step 1330, the object state data block is a group of object state data that are consecutively indexed by the state data in the index list, and the index list is a list of state data indices of object state data that have been written into the blockchain network.

[0247] It should be noted that when the state data index of the object state data contains a state data class index, the index list is a list of multiple state data indexes that have been written to the blockchain network and whose state data class indexes are the same as those of the state data index of the object state data to be queried, arranged in ascending order.

[0248] For example, in Figure 11, the index list is a list consisting of state data index a1 and state data index a4, and the index list can be represented as a1[1]-a4[2]. The object state data block includes the object state data corresponding to state data index a1 and the object state data corresponding to state data index a4.

[0249] If only the second native consolidation is received from the full-store blockchain node, it indicates that the full-store blockchain node does not store object state data whose state data index precedes the queried object state data. The state data index in the second native consolidation is the smallest state data index among the state data indexes stored on the full-store blockchain node, following the state data index of the queried object state data. Based on this, the index list to which the state data index corresponding to the queried object state data should belong is extracted from the local database of this blockchain node. Next, the first-ranked state data index and its storage sequence number are extracted from the index list. The extracted first-ranked state data index and its storage sequence number are compared with the state data index and storage sequence number in the second native consolidation provided by the full-store blockchain node. If the first-ranked state data index and its storage sequence number correspond to the state data index and its storage sequence number in the second native consolidation (the state data index is consistent, and the storage sequence number is consistent), it indicates that the full-store blockchain node is an honest node, and the reliability verification is confirmed to be successful. Otherwise, the full-store blockchain node is considered to have acted dishonestly, and the data it returned, such as the second native integrated entity, based on the request is incorrect. Therefore, the reliability verification of the full-store blockchain node is deemed unsuccessful. This blockchain node can also request the full-store blockchain node to re-return the object state data.

[0250] By adopting this embodiment, various scenarios are considered when the full-store blockchain node returns data if it continues to request the first and second native integrators when the full-store blockchain node has not returned the object state data to be queried. A corresponding verification mechanism is set for each different data feedback, which can comprehensively verify the reliability of the full-store blockchain node based on the specific circumstances of the first and second native integrators returned by the full-store blockchain node. This can improve the accuracy and comprehensiveness of verification, thereby reducing the risk of cheating by the full-store blockchain node in data query and improving the accuracy and reliability of object state data query.

[0251] Because when providing the first and second native integrators, full-store blockchain nodes may also provide native integrators corresponding to other state data indexes as the first or second native integrator. For example, the first and second native integrators provided by the full-store blockchain node may both have state data indexes belonging to object state data that precede the state data index of the object to be queried. Based on this, embodiments of this disclosure provide a scheme for verifying the correctness of the first and second native integrators based on the size relationship of the state data indexes, which can reduce the risk of full-store blockchain nodes providing erroneous data during the query phase.

[0252] In one embodiment, step 1220 specifically includes:

[0253] If the state data index in the first native consolidation, the state data index corresponding to the object state data, and the state data index in the second native consolidation increase sequentially, then the reliability verification is considered successful.

[0254] Specifically, in a blockchain, the state data indexes of various transaction objects are ordered. In particular, multiple state data indexes belonging to the same state data class have a predetermined order and size relationship. Based on this, when verifying the reliability of a full-store blockchain node, it is considered that the first native consolidation corresponds to the stored object state data whose state data index precedes the queried object state data, and the second native consolidation corresponds to the stored object state data whose state data index follows the queried object state data. Therefore, according to the predetermined order, the state data index of the first native consolidation is smaller than the state data index of the queried object state data, and the state data index of the queried object state data is smaller than the state data index in the second native consolidation. Based on this, after obtaining the first and second native consolidations from the full-store blockchain node, the blockchain node sorts the state data indexes in the first native consolidation, the state data indexes corresponding to the object state data, and the state data indexes in the second native consolidation. If the state data index in the first native consolidation, the state data index corresponding to the object state data, and the state data index in the second native consolidation increase sequentially, it indicates that the order of the state data indexes in the first and second native consolidations provided by the full-storage blockchain node is correct, and the reliability verification is confirmed to have passed. However, if the state data indexes in the first native consolidation, the state data index corresponding to the object state data, and the state data index in the second native consolidation do not increase sequentially, it indicates that the first and second native consolidations do not satisfy the adjacency relationship with the queried object state data in the state data index, and the reliability verification is confirmed to have failed.

[0255] By adopting this embodiment, the correctness of the first and second native integrated entities is verified based on the size relationship of the state data index. It requires that the state data index in the first native integrated entity provided by the full-storage blockchain node, the state data index corresponding to the object state data received by the blockchain node, and the state data index in the second native integrated entity provided by the full-storage blockchain node be sequentially increasing. This reduces the risk of the full-storage blockchain node providing incorrect data during the query phase, and enables the full-storage blockchain node to provide the most correct object state data possible, thereby improving the security of state data processing in the blockchain.

[0256] Even when a full-store blockchain node is dishonest, and despite employing the aforementioned dependencies on the first and second native integrators, as well as the size relationships between the state data indexes in the first and second native integrators and the state data index of the object to be queried, the full-store blockchain node can still modify the specific data when submitting the first and second native integrators. This allows it to successfully evade the verification process even when providing erroneous data. For example, a full-store blockchain node might intentionally change the marker in the first native integrator to the storage sequence number of the second native integrator, and simultaneously modify the state data indexes in both integrators to ensure an increasing relationship. This would lead to misjudgments in reliability verification, reducing verification accuracy. Therefore, this disclosure provides a scheme for reliability verification of full-store blockchain nodes based on digest computation, which can improve the accuracy of reliability verification.

[0257] Referring to Figure 14, in one embodiment, step 1220 specifically includes, but is not limited to, the following steps 1410-1430:

[0258] Step 1410: Obtain the fifth digest value and the sixth digest value stored by the blockchain node;

[0259] Step 1420: Perform a digest operation on the first native integrator to obtain the seventh digest value, and perform a digest operation on the second native integrator to obtain the eighth digest value;

[0260] Step 1430: If the fifth digest value is equal to the seventh digest value and the sixth digest value is equal to the eighth digest value, then the reliability verification is confirmed to be successful.

[0261] Steps 1410-1430 are described in detail below.

[0262] In step 1410, the fifth digest value corresponds to the first native integrator, and the sixth digest value corresponds to the second native integrator. The fifth digest value is the digest result generated by the blockchain node when storing object state data in the first native integrator. The sixth digest value is the digest result generated by the blockchain node when storing object state data in the second native integrator.

[0263] First, the blockchain node extracts a storage sequence number from the first native consolidation and then from the second native consolidation. Next, based on the storage sequence number in the first native consolidation, it retrieves a digest value pointed to by that storage sequence number in the local database as the fifth digest value. Simultaneously, based on the storage sequence number in the second native consolidation, it retrieves a digest value pointed to by that storage sequence number in the local database as the sixth digest value.

[0264] In step 1420, the seventh digest value is the result of the digest operation performed by the blockchain node on the first native concatenation provided by the full storage blockchain node, and the eighth digest value is the result of the digest operation performed by the blockchain node on the second native concatenation provided by the full storage blockchain node.

[0265] The blockchain node performs a digest operation on the first native concatenation obtained from the full-store blockchain node to obtain the seventh digest value, and performs a digest operation on the second native concatenation obtained from the full-store blockchain node to obtain the eighth digest value.

[0266] It should be noted that the digest algorithms used in the digest operations of this disclosure are all uniform.

[0267] In step 1430, since the contents of the first and second native integrators provided by the full-store blockchain node are both correct and unmodified, the fifth digest value will equal the seventh digest value, and the sixth digest value will equal the eighth digest value. Based on this, the blockchain node compares the fifth and seventh digest values, and compares the sixth and eighth digest values. If the fifth digest value equals the seventh digest value, and the sixth digest value equals the eighth digest value, then the reliability verification is deemed successful. If the fifth digest value does not equal the seventh digest value, and / or the sixth digest value does not equal the eighth digest value, it indicates that the full-store blockchain node has privately modified the contents of the first and / or second native integrators, and therefore the reliability verification of the full-store blockchain node is deemed unsuccessful.

[0268] By adopting this embodiment, considering that the full-store blockchain node might modify the dependencies between the first and second native integrators, as well as the state data indexes in the first and second native integrators, to circumvent reliability verification, a method is introduced in the reliability verification process: the digests of the first and second native integrators provided by the full-store blockchain node are recalculated and compared with the fifth and sixth digest values ​​stored locally. Since the fifth and sixth digest values ​​are generated by the blockchain node and are relatively reliable, the consistency between the fifth and seventh digest values ​​can be used to identify whether the full-store blockchain node has modified the first native integrator, and the consistency between the sixth and eighth digest values ​​can be used to identify whether the full-store blockchain node has modified the second native integrator. This improves the comprehensiveness and accuracy of reliability verification. Even if the full-store blockchain node maliciously modifies the dependencies between the first and second native integrators, as well as the state data indexes in the first and second native integrators, the blockchain node can still easily identify the cheating behavior of the full-store blockchain node, thereby improving the accuracy of object state data queries.

[0269] Figure 15 illustrates an example of how, after writing the object state data associated with four transactions into the blockchain, object state data with different state data indices can be queried. Specifically, the object state list includes transactions 1, 2, 3, and 4 executed sequentially. After transaction 1 is completed, it is associated with object state data va1 for object with state data index a1; after transaction 2 is completed, it is associated with object state data va2 for object with state data index a2; after transaction 3 is completed, it is associated with object state data va5 for object with state data index a5; and after transaction 4 is completed, it is associated with object state data vb2 for object with state data index b2. Furthermore, blockchain node 1 (Node1) is the blockchain node that stores all object state data for object with state data class index 'a', and blockchain node 2 (Node2) is the blockchain node that stores all object state data for object with state data class index 'b'. Based on this, according to the rules for storing object state data in this embodiment, blockchain node 1 records the complete content of three plaintext object state data, the digest of one ciphertext object state data, and the value range of the state data index of the object state data already stored on blockchain node 2. Specifically, the three plaintext object state data are {index: 1, key = a1, value = va1, next: 2}, {index: 2, key = a2, value = va2, next: 3}, and {index: 3, key = a5, value = va5, next: 0}, the digest of the ciphertext object state data is {h4 = Hash(b2: vb2:4:0)}, and the value range of the state data index of the object state data already stored on blockchain node 2 is “Node2-b2[4]-b2[4]”. Blockchain node 2 records the digest of three ciphertext object state data, the complete content of one plaintext object state data, and the value range of the state data index of the object state data already stored on blockchain node 2. Specifically, the digests of the object state data of the three ciphertexts are {h1=Hash(a1:va1:1:2)}, {h2=Hash(a2:va2:2:3)}, and {h3=Hash(a5:va5:3:0)}, respectively. The object state data of the plaintext is {index:4,key=b2,value=vb2,next:0}. The range of the state data index of the object state data already stored on blockchain node 1 is “Node1-a1[1]-a5[3]”.

[0270] Scenario 1: When a request is made to blockchain node 2 to query the object state data with state data index a2, blockchain node 2 sends state data index a2 to blockchain node 1. At this time, blockchain node 1 retrieves a stored data record with storage sequence number 2 based on state data index a2. This stored data record has state data index a2, object state data va2 with storage sequence number 2, and a tag of 3. Based on this, blockchain node 1 sends this stored data as a native concatenation to blockchain node 2. Blockchain node 2 then extracts a digest value h2 from its local storage based on storage sequence number 2, performs a digest operation using the received native concatenation, and compares the resulting digest value with digest value h2. If the digest value matches digest value h2, it indicates that the object state data in the native concatenation is the data being queried. If the digest value does not match digest value h2, it indicates that the object state data in the native concatenation is not the data being queried.

[0271] Furthermore, if blockchain node 1 cheats by not sending the native integrator corresponding to state data index a2 to blockchain node 2, but instead claims that it does not store the native integrator corresponding to state data index a2 locally, then blockchain node 2 will request the full-storage blockchain node (i.e., blockchain node 1) to provide the first and second native integrators. At this point, the full-storage blockchain node (i.e., blockchain node 1) will provide the first native integrator corresponding to state data index a1 and the second native integrator corresponding to state data index a5. However, blockchain node 2 will detect that the first native integrator corresponding to state data index a1 is marked as 2, while the second native integrator corresponding to state data index a5 is marked as 3. This discrepancy between the markings and the storage sequence number will identify the dishonest behavior of blockchain node 1.

[0272] Furthermore, if blockchain node 1 modifies the tag of the first native integrator corresponding to state data index a1 to 3, then blockchain node 2, when performing digest calculations using this tag and other data within the first native integrator, will calculate a digest value h1 that is inconsistent with the digest value h1 stored in its local database with storage sequence number 1. This is because the digest value h1 was calculated using the tag 1.

[0273] Scenario 2: When a request is made to blockchain node 2 to query the state data of an object with state data index a3, blockchain node 2 will send state data index a3 to blockchain node 1. At this time, blockchain node 1 will not find the corresponding data based on state data index a3. Therefore, blockchain node 1 will provide the first native integrator corresponding to state data index a2 and the second native integrator corresponding to state data index a5. Based on this, blockchain node 2 will first check that the marker in the first native integrator is 3, which matches the storage sequence number 3 in the second native integrator. Next, blockchain node 2 will check that the state data index a2 in the first native integrator, the state data index a3 of the object to be queried, and the state data index a5 in the second native integrator are sequentially increasing. Furthermore, blockchain node 2 concatenates and performs a digest operation using state data index a2, storage sequence number 2, tag 3, and object state data va2 from the first native concatenation, obtaining a digest value consistent with the digest value h2 with storage sequence number 2 in local storage. Simultaneously, blockchain node 2 concatenates and performs a digest operation using state data index a5, storage sequence number 3, tag 0, and object state data va5 from the second native concatenation, obtaining a digest value consistent with the digest value h3 with storage sequence number 3 in local storage. Based on this, blockchain node 2 considers the reliability verification of blockchain node 1 to be successful and provides feedback with the query result that the object state data corresponding to state data index a3 is not stored.

[0274] Scenario 3: When a request is made to blockchain node 2 to query the object state data with state data index a6, blockchain node 2 will send state data index a6 to blockchain node 1. At this time, blockchain node 1 will not find the corresponding data based on state data index a6. Therefore, blockchain node 1 will only provide blockchain node 2 with the first native concatenation of object state data whose state data index precedes state data index a6. Based on this, blockchain node 2 will receive the first native concatenation corresponding to state data index a5. Blockchain node 2 will first check the flag of the first native concatenation and find that the flag is 0. Then, blockchain node 2 will extract the last state data index and its corresponding storage sequence number from the index list recording the state data indexes of blockchain node 1. Since the extracted state data index is a5, and its corresponding storage sequence number is 3, which is consistent with the state data index and storage sequence number in the first native concatenation, blockchain node 2 will further determine that the state data index a5 in the first native concatenation and the state data index a6 of the object state data to be queried are increasing. Next, the state data index a5, storage sequence number 3, tag 0, and object state data va5 from the first native concatenation are concatenated and a digest operation is performed to obtain a digest value that is consistent with the digest value h3 with storage sequence number 3 stored locally. Based on this, blockchain node 2 considers the reliability verification of blockchain node 1 to be successful and provides feedback with the query result that the object state data corresponding to the state data index a6 is not stored.

[0275] Scenario 4: When a request is made to blockchain node 1 to query the object state data with state data index b1, blockchain node 1 will send state data index b1 to blockchain node 2. At this point, blockchain node 2 will not find the corresponding data based on state data index b1. Therefore, blockchain node 2 will only provide blockchain node 1 with the second native integrated body of the object state data whose state data index follows that of state data index b1. Based on this, blockchain node 1 will receive the second native integrated body corresponding to state data index b2. Blockchain node 1 will first check the flag of the second native integrated body and find that the flag is 0. Then, blockchain node 1 will extract the first state data index and its corresponding storage sequence number from the index list recording the state data indexes of blockchain node 2. Since the extracted state data index is b2, and its corresponding storage sequence number is 4, which is consistent with the state data index and storage sequence number in the second native integrated body, blockchain node 1 will further determine that the state data index b1 of the object state data to be queried and the state data index b2 in the second native integrated body are incremental. Next, the state data index b2, storage sequence number 4, tag 0, and object state data vb2 from the second native concatenation are concatenated and digested to obtain a digest value h4 that is consistent with the digest value h4 stored locally with storage sequence number 4. Based on this, blockchain node 1 considers the reliability verification of blockchain node 2 to be successful and provides feedback with the query result that the object state data corresponding to the state data index b1 is not stored.

[0276] The following is a detailed description of the processing procedure for a blockchain node that is a full-store blockchain node in one embodiment of this disclosure.

[0277] Referring to Figure 16, in one embodiment, after determining the full storage blockchain node for storing object state data from the blockchain network based on the state data index, the blockchain processing method further includes, but is not limited to, the following steps 1610-1630:

[0278] Step 1610: If the blockchain node is a full storage blockchain node, assign a storage sequence number to the object state data, and store the object state data, state data index and storage sequence number in the blockchain node accordingly.

[0279] Step 1620: Receive a query request for object status data;

[0280] Step 1630: Determine that the blockchain node is a full-storage blockchain node based on the state data index, and search for the object state data based on the state data index.

[0281] Steps 1610-1630 are described in detail below.

[0282] In step 1610, if the blockchain node is a full-storage blockchain node, it indicates that the blockchain node needs to store the complete content of the object state data. Based on this, the full-storage blockchain node will first search its local database according to the state data index. If the state data index exists in the local database, it indicates that the transaction object has already stored object state data in the full-storage blockchain node. Then, it directly searches for the storage order of the state data index in the full-storage blockchain node, obtains the previously allocated storage sequence number, and replaces the originally stored object state data with the newly received object state data, ensuring that the newly received object state data, the state data index, and the previously allocated storage sequence number are stored accordingly. If the state data index is not found in the local database, it indicates that the transaction object has not stored object state data in the full-storage blockchain node. Therefore, the full-storage blockchain node will allocate a new storage sequence number to the transaction object according to the storage order and store the object state data, the state data index, and the newly allocated storage sequence number accordingly.

[0283] In step 1620, the query request includes a status data index.

[0284] The specific process of step 1620 is similar to that of step 350 above.

[0285] In step 1630, when the state data index determines that the blockchain node is a full-storage blockchain node, the local database of this blockchain node will contain the complete content of the state data of each object. Based on this, the full-storage blockchain node will find the object state data corresponding to the state data index according to the state data index, the locally recorded object state data, and the relationship between the state data index and the storage sequence number. Furthermore, when the full-storage blockchain node finds the object state data corresponding to the state data index in its local database, it will return the object state data as the query result.

[0286] As shown in Figure 16, when a request is made to blockchain node 1 to query the object state data with state data index a5, blockchain node 1 will find the object state data va5 corresponding to state data index a5 in its local database. Therefore, blockchain node 1 can directly provide the object state data va5 as the query result.

[0287] By adopting this embodiment, when storing object state data on a full-storage blockchain node, there is a corresponding storage sequence number. When a query request is received, the full-storage blockchain node storing the object state data to be queried can be uniquely determined based on the state data index. Based on the storage sequence number, the location of the object state data stored on that full-storage blockchain node can be obtained. Thus, when the blockchain node is a full-storage blockchain node, the object state data can be obtained directly from the full-storage blockchain node based on the state data index, improving the query efficiency of object state data.

[0288] Figure 17 illustrates the overall process of querying object state data in a blockchain according to one embodiment of this disclosure. Specifically, when an object wants to find the data corresponding to a certain state data index key, it sends a query request to blockchain node 1 in the blockchain network. At this time, blockchain node 1 calculates the node corresponding to the state data index key according to the sharding rules and determines whether it stores the transaction object data corresponding to the key locally. If blockchain node 1 is a full-store blockchain node and its local database contains the data corresponding to the state data index key, it returns the found object state data corresponding to the state data index to the object. Further, if blockchain node 1 is not a full-store blockchain node, then blockchain node 1 does not have the complete content of the object state data corresponding to the state data index locally. Based on this, blockchain node 1 generates a get request and sends the get request to other blockchain nodes (e.g., blockchain node 2). Then, it checks whether the object state data corresponding to the state data index key is stored in the local database of blockchain node 2. When blockchain node 2 is a full-storage blockchain node and its local database contains the object state data corresponding to the state data index key, blockchain node 2 will return all data (object state data, tag, and storage sequence number) corresponding to the state data index key to blockchain node 1. At this time, blockchain node 1 will parse the data, obtaining the object state data value, tag next, and storage sequence number index corresponding to the state data index key; it will then retrieve the digest value h0 corresponding to the storage sequence number from its local database, where h0 = h{$index}. Based on the state data index key, object state data value, tag next, and storage sequence number index, it will calculate the digest value h1. If the digest value h1 equals the digest value h0, it will return the object state data returned by blockchain node 2 as the query result. If the digest value h1 does not equal the digest value h0, blockchain node 1 will return to the step of generating a GET request and sending it to other blockchain nodes. When blockchain node 2 is a full-store blockchain node and the object state data corresponding to the state data index key does not exist in its local database, blockchain node 2 will obtain the preceding storage node (first adjacent object state data) and the following storage node (second adjacent object state data) corresponding to the state data index, and return the preceding data information (first native integrated body) and the following data information (second native integrated body) to blockchain node 1. At this time, blockchain node 1 will parse the data and obtain the first native integrated body *pre* and the second native integrated body *next* sent by blockchain node 2. First, blockchain node 1 will determine whether the state data index key is between the state data index key in the first native integrated body *pre* and the state data index key in the second native integrated body *next*.If the state data index key is not between the state data index key in the first native integrator `pre` and the state data index key in the second native integrator `next`, then blockchain node 1 will return to the step of generating a GET request and sending it to other blockchain nodes. If the state data index key is between the state data index key in the first native integrator `pre` and the state data index key in the second native integrator `next`, then blockchain node 1 retrieves the digest value `hpre0` corresponding to `h{$pre_index}` and the digest value `hnext0` corresponding to `h{$next_index}` from its local database, and calculates the digest value `hpre1` based on the first native integrator and the digest value `hnext1` based on the second native integrator. If `hnext1 = hnext0` and `hpre1 = hpre0`, then a message indicating that no relevant stored data was found for that state data index is returned to the object. If `hnext1` is not equal to `hnext0` and / or `hpre1` is not equal to `hpre0`, then blockchain node 1 will return to the step of generating a GET request and sending it to other blockchain nodes.

[0289] It should be noted that the get request in the above embodiment refers to the request by blockchain node 1 to obtain the stored data associated with the state data index key from other blockchain nodes based on the state data index key.

[0290] The following is a detailed description of one embodiment of this disclosure, showing the process by which the blockchain node updates the tag corresponding to the stored object state data.

[0291] Since new object state data written to the blockchain network can cause changes to the tags of some object state data that are associated with the newly written object state data, this disclosure provides a scheme to update the tags of object state data already recorded on the blockchain when new object state data is written to the blockchain network, which can improve the security and accuracy of object state data recorded on the blockchain.

[0292] Referring to Figure 18, in one embodiment, in response to the blockchain node being different from the full storage blockchain node, the object state data is sent to the full storage blockchain node so that the full storage blockchain node stores the object state data, the state data index, and the storage sequence number accordingly. The blockchain processing method further includes, but is not limited to, the following steps 1810-1830:

[0293] Step 1810: Request the first native integrated data of the first adjacent object state data and the second native integrated data of the second adjacent object state data from the full storage blockchain node;

[0294] Step 1820: Verify the first and second native integrators;

[0295] Step 1830: If the verification passes, change the marker in the first native integrator to the storage sequence number of the object state data.

[0296] Steps 1810-1830 are described in detail below.

[0297] In step 1810, the state data index of the first adjacent object state data is ranked before the object state data in the full-store blockchain node, and the state data index of the second adjacent object state data is ranked after the object state data in the full-store blockchain node.

[0298] The specific process of step 1810 is similar to that of step 1210 above. The difference is that step 1210 obtains the first and second native integrators during the data query stage, while step 1810 obtains the first and second native integrators during the data storage stage.

[0299] In step 1820, the verification of the first native integrator and the second native integrator may be performed in one or more of the following ways:

[0300] Method 1: If the tag in the first native integrator is equal to the storage sequence number in the second native integrator, then the verification is successful.

[0301] The implementation process of Method 1 is similar to step 1310 above. The difference is that step 1310 is the verification in the data query stage, while Method 1 is the verification in the data storage stage.

[0302] Method 2: If the state data index in the first native concatenation, the state data index corresponding to the object state data, and the state data index in the second native concatenation increase sequentially, then the verification is considered successful.

[0303] The implementation process of Method 2 is similar to one of the reliability verification methods in step 1220 above. The difference is that the reliability verification method in step 1220 above is a verification in the data query stage, while Method 2 is a verification in the data storage stage.

[0304] In step 1830, if the verification passes, it indicates that the first and second native integrators provided by the full-store blockchain node are correct. Based on this, the blockchain node will change the marker in the first native integrator to the storage sequence number of the object state data, and use the storage sequence number in the second native integrator as the marker corresponding to the object state data.

[0305] Furthermore, since this blockchain node stores the digest value of the object state data corresponding to the first native integrator, and also needs to store the digest value of the object state data to be written, the blockchain node concatenates and performs a digest operation on the state data index, object state data, storage sequence number, and modified tag (the tag being the storage sequence number corresponding to the object state data to be stored) in the first native integrator, obtaining a digest result. This digest result replaces the specific content of the digest value originally corresponding to the storage sequence number in the first native integrator stored in the local database. Similarly, the blockchain node concatenates and performs a digest operation on the object state data to be stored, state data index, determined storage sequence number, and tag (the tag being the storage sequence number in the second native integrator), obtaining a digest result. This digest result is then stored as the first digest value corresponding to the object state data and its corresponding storage sequence number.

[0306] By adopting this embodiment, when new object state data is written to the blockchain network, the corresponding markers of the object state data already recorded on the blockchain are updated, which can improve the accuracy of the object state data recorded on the blockchain. At the same time, when new object state data is written to the blockchain network, a combination of multiple verification methods is used, which can improve the accuracy of writing object state data. Thus, while ensuring the security of object state data, the space occupation of the blockchain network is reduced and the resource utilization of the blockchain network is improved.

[0307] Because blockchain nodes in full-store storage may engage in cheating by privately modifying the contents of the relevant first and second native integrators to circumvent verification when writing new object state data, errors may occur during the writing process, affecting the security and accuracy of the object state data recorded on the blockchain. Therefore, this disclosure provides a scheme for performing digest verification during the data writing process, which can improve the accuracy of object state data writing.

[0308] Referring to Figure 19, in one embodiment, step 1830 specifically includes, but is not limited to, the following steps 1910-1930:

[0309] Step 1910: Obtain the fifth digest value and the sixth digest value stored by the blockchain node;

[0310] Step 1920: Perform a digest operation on the first native integrator to obtain the seventh digest value, and perform a digest operation on the second native integrator to obtain the eighth digest value;

[0311] Step 1930: If the fifth digest value equals the seventh digest value, and the sixth digest value equals the eighth digest value, then the verification is successful.

[0312] Steps 1910-1930 are described in detail below.

[0313] In step 1910, the fifth digest value corresponds to the first native integrand, and the sixth digest value corresponds to the second native integrand.

[0314] Steps 1910-1930 are similar to steps 1410-1430 above. The difference is that steps 1910-1930 are digest verification in the data writing stage, while steps 1410-1430 are digest verification in the data query stage. The verification stages are different.

[0315] By adopting this embodiment, digest verification is performed during the data writing process. Digest operations are performed on the first and second native integrators provided by the full-store blockchain node to obtain the seventh and eighth digest values. The seventh digest value is verified using the accurate and reliable fifth digest value stored in the local database, and the eighth digest value is verified using the accurate and reliable sixth digest value stored in the local database. This reduces the occurrence of cheating behavior where the full-store blockchain node privately modifies the specific content of the relevant first and second native integrators when writing new object state data, thereby improving the accuracy of object state data writing and the accuracy of updating the tags of stored object state data related to object state data.

[0316] The following describes, with reference to Figures 20A-20E, a specific example of the process of writing object state data into a blockchain network in an embodiment of this disclosure.

[0317] As shown in Figure 20A, an object state data list contains four transactions executed sequentially: Transaction 1, Transaction 2, Transaction 3, and Transaction 4. Transaction 1 is associated with object state data va1 (state data index a1), Transaction 2 with object state data va2 (state data index a2), Transaction 3 with object state data va5 (state data index a5), and Transaction 4 with object state data va3 (state data index a3). Then, each transaction is written into the blockchain in sequence. Based on this, when blockchain node 1 is the full storage blockchain node corresponding to state data with class index 'a', blockchain node 1 stores the complete content of the object state data with class index 'a' (such as transaction object state value, storage sequence number index, and tag next). Specifically, the first data recorded in blockchain node 1 is the object state va1 corresponding to state data index a1 with storage sequence number 1 and label 2; the second data recorded is the object state va2 corresponding to state data index a2 with storage sequence number 2 and label 4; the third data recorded is the object state va5 corresponding to state data index a5 with storage sequence number 3 and label 0; and the fourth data recorded is the object state va3 corresponding to state data index a3 with storage sequence number 4 and label 3. Blockchain node 2 correspondingly records the first digest values ​​for these four object state data entries, as well as the value range of the state data indices stored in blockchain node 1. Specifically, the first digest value recorded by blockchain node 2 is h1, which is obtained by performing a digest operation on the object state va1 corresponding to state data index a1 with storage sequence number 1 and label 2. The second digest value recorded is h2, which is obtained by performing a digest operation on the object state va2 corresponding to state data index a2 with storage sequence number 2 and label 4. The third first digest value of the record is h3, which is obtained by performing a digest operation on the object state va5 corresponding to the state data index a5 with storage sequence number 3 and label 0. The fourth first digest value of the record is h4, which is obtained by performing a digest operation on the object state va3 corresponding to the state data index a3 with storage sequence number 4 and label 3. In addition, the blockchain node 2 records the range of values ​​of the state data index stored in the blockchain node 1 as a1[1]-a5[3].

[0318] As shown in Figure 20B, when writing the object state data va4 associated with the state data index a4 of transaction 5 in a new block into the blockchain, blockchain node 2 first sends a request to blockchain node 1 to append the object state data. Next, blockchain node 1 searches its local database for the object state data corresponding to the state data index a4 most recently, before a4. It finds the object state data corresponding to state data index a3 as the first native integrator, and then searches for the object state data corresponding to the state data index a4 most recently, after a4, and finds the object state data corresponding to state data index a5 as the second native integrator. Further, blockchain node 1 returns the first and second native integrators to blockchain node 2. At this point, blockchain node 1 will allocate a storage sequence number of index = 5 for state data index a4 locally; it will insert state data index a4 between state data indexes a3 and a5, that is, update the tag of state data index a3 from 3 to the storage sequence number of state data index a4 as 5; it will set the tag of state data index a4 to the storage sequence number of state data index a5 as 3, thereby updating the tag corresponding to the locally stored state data index a3, and storing the object state data va4, storage sequence number 5, and tag 3 of state data index a4 accordingly. Meanwhile, in blockchain node 2, blockchain node 2 first determines whether the tag of state data index a3 is equal to the storage sequence number of state data index a5. Since the tag is 3, it is equal to the storage sequence number 3. The next step is to check if a3 < a4 < a5 is true. Since state data indices a3, a4, and a5 satisfy this increasing relationship, blockchain node 2 calculates a digest value Hash'(a3:va3:4:3) based on the first native concatenation returned by blockchain node 1, and calculates a digest value Hash'(a5:va5:3:0) based on the second native concatenation returned by blockchain node 1. It then compares the digest value Hash'(a5:va5:3:0) with the locally stored digest value h3, and compares the digest value Hash'(a3:va3:4:3) with the locally stored digest value h4. Since the digest value Hash'(a5:va5:3:0) equals the digest value h3, and the digest value Hash'(a3:va3:4:3) equals the digest value h4, the verification is successful. A storage sequence number of 5 is assigned to state data index a4, the tag of state data index a3 is updated to 5, and the tag of state data index a4 is set to 3. Furthermore, update the first digest value h4 corresponding to the state data index a3, so that the first digest value h4 = Hash(a3:va3:4:5), and add the corresponding first digest value h5, where the first digest value h5 = Hash(a4:va4:5:3).

[0319] As shown in Figure 20C, after the object state data va4 corresponding to state data index a4 is recorded in the blockchain, blockchain node 1 has an additional plaintext storage record, that is, a record with storage sequence number 5, tag 3, state data index a4, and object state data va4. Simultaneously, the tag corresponding to state data index a3 recorded in blockchain node 1 is changed from 3 to 5. Similarly, blockchain node 2 has an additional digest storage record, that is, a digest value h5 is recorded, and the specific content of the originally recorded digest value h4 is also changed.

[0320] As shown in Figure 20D, when writing object state data va6 associated with state data index a6 of transaction 5 in a new block into the blockchain, blockchain node 2 first sends a request to blockchain node 1 to append object state data. Next, blockchain node 1 searches its local database for object state data corresponding to the nearest state data index to state data index a6, before a6. It finds the object state data corresponding to state data index a5 as the first native integrator and then searches for object state data corresponding to the nearest state data index to state data index a6 after a6, but finds no relevant data. Furthermore, blockchain node 1 returns the first native integrator to blockchain node 2. At this time, blockchain node 1 will allocate a storage sequence number of index=5 for state data index a6 locally; update the tag of state data index a5 from 0 to the storage sequence number of state data index a6 as 5; set the tag of state data index a6 to 0, so as to update the tag corresponding to state data index a5 stored locally, and store the object state data va6, storage sequence number 5 and tag 0 of state data index a6 accordingly. In blockchain node 2, blockchain node 2 first determines whether state data index a5 is the largest value in the local storage range, since the largest value is a5[3]. Then it continues to determine whether a5<a6 is true. Since state data index a5 and state data index a6 satisfy this increasing relationship, blockchain node 2 will calculate a digest value Hash'(a5:va5:3:0) based on the first native integrator returned by blockchain node 1, and compare the digest value Hash'(a5:va5:3:0) with the digest value h3 stored locally. Since the digest value Hash'(a5:va5:3:0) is equal to the digest value h3, the verification is successful. The storage sequence number 5 is allocated to the state data index a6, and the flag of the state data index a5 is updated to 0. The flag of the state data index a6 is set to 0. Further, the first digest value h3 corresponding to the state data index a5 is updated so that the first digest value h3 = Hash(a5:va5:3:5), and the corresponding first digest value h5 is added, where the first digest value h5 = Hash(a6:va6:5:0). At the same time, the largest value in the range is updated to a6[5].

[0321] As shown in Figure 20E, after the object state data va6 corresponding to the state data index a6 is recorded in the blockchain, a plaintext storage data is added to blockchain node 1, that is, a data with storage sequence number 5, tag 0, state data index a6, and object state data va6 is recorded. At the same time, the tag corresponding to the state data index a5 recorded in blockchain node 1 is changed from 0 to 5. Similarly, a digest storage data is added to blockchain node 2, that is, a digest value h5 is recorded, and the specific content of the originally recorded digest value h3 is also changed. At the same time, the value range of the state data index of blockchain node 1 recorded in blockchain node 2 is updated to a1[1]-a6[5].

[0322] Figure 21 illustrates the overall process of writing object state data into the blockchain in one embodiment of this disclosure. Specifically, when an object submits object state data to blockchain node 1, blockchain node 1 first calculates the node corresponding to the state data index key according to the sharding rules. When blockchain node 1 is the full storage blockchain node corresponding to the state data index key, it determines whether the object state data corresponding to the key is stored locally. If the object state data corresponding to the key is stored locally, the value is updated to the corresponding value if the key exists locally; if the key does not exist locally, a new storage sequence number (index) is generated, and the object state data and storage sequence number are stored accordingly, similar to steps 720-730 above. When blockchain node 1 is not the full storage blockchain node corresponding to the state data index key, blockchain node 1 generates a get request and sends it to other blockchain nodes (taking blockchain node 2 as an example). When blockchain node 2 receives a GET request, if blockchain node 2 is a full-storage blockchain node and its local database contains the object state data corresponding to the state data index key, then blockchain node 2 will return all data corresponding to the state data index key (object state data, tag, and storage sequence number) to blockchain node 1. At this time, blockchain node 1 will parse the data, obtaining the object state data value, tag next, and storage sequence number index corresponding to the state data index key; it will also retrieve the digest value h0 corresponding to the storage sequence number from its local database, where h0 = h{$index}. Based on the state data index key, object state data value, tag next, and storage sequence number index, it will calculate the digest value h1. If the digest value h1 equals the digest value h0, then blockchain node 1 will set the stored object state data to the new object state data, replacing the historical object state data provided by blockchain node 2 with the new object state data, and setting the stored value to the new object state data value, the storage sequence number index provided by blockchain node 2, and the tag next. Finally, it will write the state data index key and the stored value to its local ledger. When the digest value h1 is not equal to the digest value h0, blockchain node 1 will return to the step of generating a get request and sending a get request to other blockchain nodes, the specific process of which is similar to step 810 above. When blockchain node 2 is a full storage blockchain node and the object state data corresponding to the state data index key does not exist in the local database, blockchain node 2 will obtain the preceding storage node (first adjacent object state data) and the following storage node (second adjacent object state data) corresponding to the state data index, and return the preceding data information (first native integrated body) and the following data information (second native integrated body) to blockchain node 1.At this point, blockchain node 1 parses the data and obtains the first native integrator `pre` and the second native integrator `next` sent by blockchain node 2. First, blockchain node 1 determines whether the state data index key is between the state data index key in the first native integrator `pre` and the state data index key in the second native integrator `next`. If the state data index key is not between these two indices, blockchain node 1 returns to the step of generating a GET request and sending it to other blockchain nodes. If the state data index key is between these two indices, blockchain node 1 retrieves the digest value `hpre0` corresponding to `h{$pre_index}` and the digest value `hnext0` corresponding to `h{$next_index}` from its local database, and calculates the digest value `hpre1` based on the first native integrator and the digest value `hnext1` based on the second native integrator. When hnext1 = hnext0 and hpre1 = hpre0, blockchain node 1 generates a new storage sequence number `index` as the storage sequence number corresponding to the state data index. It uses the storage sequence number of the second native integrator as the marker corresponding to the state data index, sets the marker `next` of the first native integrator `pre` to the newly generated storage sequence number `index`, and sets the value of the storage corresponding to the state data index `key` to `value`, `index`, and `index_pre_next`. Simultaneously, it performs a digest calculation on the state data index `key` and its corresponding storage value to generate a first digest value corresponding to the state data index. This first digest value is stored in the local ledger along with the corresponding storage sequence number. The marker in the first native integrator is replaced with the storage sequence number corresponding to the state data index `key`, and a digest calculation is performed again to obtain a digest value. This digest value replaces the digest value `hpre0` corresponding to the storage sequence number in the first native integrator in the local database and is then stored. However, when hnext1 ≠ hnext0 and / or hpre1 ≠ hpre0, blockchain node 1 returns to the step of generating a GET request and sending a GET request to other blockchain nodes.

[0323] This disclosure can improve the resource utilization of blockchain networks while ensuring the security of object state data. This disclosure can be applied to various scenarios such as blockchain and artificial intelligence.

[0324] The apparatus and device according to embodiments of this disclosure will now be described.

[0325] Although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this embodiment, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0326] It should be noted that in various specific embodiments of this application, when processing is required based on data related to object characteristics, such as object attribute information or sets of attribute information, the permission or consent of the object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application need to obtain object attribute information, separate permission or consent from the object will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the object's separate permission or consent will the necessary object-related data for the proper functioning of the embodiments of this application be obtained.

[0327] Figure 22 is a schematic diagram of the structure of a blockchain processing device 2200 provided in an embodiment of this disclosure. The blockchain processing device 2200 is executed by a blockchain node in a blockchain network, and includes:

[0328] Execution unit 2210 is configured to respond to a block on-chain request and determine an object state list based on state update data corresponding to at least one transaction object in the block. The object state list includes object state data of at least one transaction object, and the object state data has a state data index for referring to the transaction object.

[0329] The determining unit 2220 is used to determine the full storage blockchain node for storing object state data in the blockchain network based on the state data index.

[0330] The sending unit 2230 is used to send object state data to the full storage blockchain node in response to the fact that the blockchain node is different from the full storage blockchain node, so that the full storage blockchain node stores the object state data, the state data index and the storage sequence number accordingly. The storage sequence number is used to indicate the storage order of the object state data in the full storage blockchain node.

[0331] The generation unit 2240 is used to generate a first digest value of the object state data and store the first digest value and storage sequence number in the blockchain node.

[0332] The receiving unit 2250 is used to receive a query request for object status data, wherein the query request includes a status data index;

[0333] Verification unit 2260 is used to determine the full storage blockchain node for storing object state data based on the state data index, request object state data and storage sequence number from the full storage blockchain node based on the state data index, query the first digest value based on the storage sequence number in the blockchain node, and use the first digest value to verify the object state data.

[0334] A blockchain network comprises multiple blockchain nodes, each of which has a blockchain node identifier.

[0335] The determining unit 2220 is used for:

[0336] Perform a modulo operation between the state data index and the number of multiple blockchain nodes to obtain the remainder;

[0337] Based on this remainder, the blockchain node identifier of the full-scale storage blockchain node is determined.

[0338] Based on the blockchain node identifier, the blockchain nodes for full storage are identified.

[0339] The state data index contains a state data class index;

[0340] The remainder is obtained by performing a modulo operation between the state data index and the number of multiple blockchain nodes. This includes performing a modulo operation between the state data index and the number of multiple blockchain nodes to obtain the remainder.

[0341] The transmitting unit 2230 is used for:

[0342] In response to the fact that this blockchain node is different from the full-store blockchain node, the object state data is sent to the full-store blockchain node;

[0343] If the historical object state data corresponding to the stored state data index on the blockchain node is fully stored, the historical object state data is updated with the object state data.

[0344] If the historical object state data corresponding to the state data index is not stored on the full storage blockchain node, a storage sequence number is assigned to the object state data, and the object state data, state data index and storage sequence number are stored in the full storage blockchain node.

[0345] The generation unit 2240 includes:

[0346] The first generation module (not shown) is used to generate a first digest value and update the second digest value with the first digest value if the second digest value of the historical object state data corresponding to the state data index has been stored on the blockchain node.

[0347] The second generation module (not shown) is used to generate a first digest value if the second digest value of the historical object state data corresponding to the state data index is not stored on the blockchain node, and to store the first digest value and the storage sequence number on the blockchain node.

[0348] The first generation module (not shown) is used for:

[0349] If the second digest value of the historical object state data corresponding to the state data index has been stored on the blockchain node, then the historical object state data corresponding to the state data index is obtained from the full storage blockchain node.

[0350] Perform a digest operation on the historical object state data to obtain a third digest value;

[0351] If the second digest value matches the third digest value, then the first digest value is generated, and the second digest value is updated with the first digest value.

[0352] The generation unit 2240 is used for:

[0353] The object state data is combined with the storage sequence number, for example, by concatenation, to obtain the original data, hereinafter referred to as the native integrator; the native integrator is then digested to obtain the first digest value.

[0354] Verification unit 2260 is used for:

[0355] The system receives object state data and storage sequence number from the full storage blockchain node; combines the received object state data with the storage sequence number, for example, by concatenating them, to obtain combined data, hereinafter referred to as the regenerated integrator; performs a digest operation on the regenerated integrator to obtain a fourth digest value; and verifies the object state data based on the first digest value and the fourth digest value.

[0356] The transmitting unit 2230 is used for:

[0357] In response to the fact that the blockchain node is different from the full storage blockchain node, the object state data is sent to the full storage blockchain node so that the full storage blockchain node can integrate the object state data, storage sequence number and tag to obtain the original integrated object state data and store the original integrated object state data. The tag is the storage sequence number of the second adjacent object state data after the object state data in the state data index. If there is no second adjacent object state data after the object state data in the state data index, the tag is the first value.

[0358] The generation unit 2240 is used for:

[0359] The native consolidation is obtained from the full-scale storage blockchain node, and a digest operation is performed on the native consolidation to obtain the first digest value.

[0360] The blockchain processing device 2200 further includes a first request unit (not shown), which includes:

[0361] The first request module (not shown) is used to request a first native concatenation of the first adjacent object state data and a second native concatenation of the second adjacent object state data from the full storage blockchain node if the object state data and storage sequence number are not received from the full storage blockchain node. The state data index of the first adjacent object state data is placed before the object state data, and the state data index of the second adjacent object state data is placed after the object state data.

[0362] The first verification module (not shown) is used to perform reliability verification on all storage blockchain nodes based on the first native integration and the second native integration.

[0363] The first verification module (not shown) is used for:

[0364] If the first and second native consolidates are received from the full-store blockchain node, and the tag in the first native consolidate is equal to the storage sequence number in the second native consolidate, then the reliability verification is confirmed to be successful.

[0365] If only the first native consolidation is received from the full-store blockchain node, and the tag in the first native consolidation is the first value, then the reliability verification is considered successful.

[0366] If the second native consolidation is received from the full-store blockchain node, and based on the index list, it is determined that the object state data is the object state data with the smallest state data index in an object state data block, then the reliability verification is considered successful. Here, an object state data block is a collection of multiple object state data with consecutive state data indices in the index list, and the index list is a list of state data indices of object state data that have been written into the blockchain network.

[0367] The first verification module (not shown) is used for:

[0368] If the state data index in the first native consolidation, the state data index corresponding to the object state data, and the state data index in the second native consolidation increase sequentially, then the reliability verification is considered successful.

[0369] The first verification module (not shown) is used for:

[0370] Obtain the fifth digest value and the sixth digest value stored by the blockchain node, wherein the fifth digest value corresponds to the first native integrator and the sixth digest value corresponds to the second native integrator;

[0371] Perform a digest operation on the first native integrator to obtain the seventh digest value, and perform a digest operation on the second native integrator to obtain the eighth digest value;

[0372] If the fifth digest value equals the seventh digest value, and the sixth digest value equals the eighth digest value, then the reliability verification is considered successful.

[0373] The blockchain processing device 2200 further includes a second request unit (not shown), which includes:

[0374] The second request module (not shown) is used to request the first native integrated body of the state data of the first adjacent object and the second native integrated body of the state data of the second adjacent object from the full storage blockchain node. The state data index of the first adjacent object is ranked before the state data index corresponding to the object state data in the full storage blockchain node, and the state data index of the second adjacent object is ranked after the state data index corresponding to the object state data in the full storage blockchain node.

[0375] The second verification module (not shown) is used to verify the first native integrator and the second native integrator;

[0376] A modification module (not shown) is used to change the marker in the first native integrator to the storage sequence number of the object state data if the verification passes.

[0377] The second verification module (not shown) is used for:

[0378] If the tag in the first native integrator is equal to the storage sequence number in the second native integrator, then the verification is considered successful.

[0379] The second verification module (not shown) is used for:

[0380] If the state data index in the first native concatenation, the state data index corresponding to the object state data, and the state data index in the second native concatenation increase sequentially, then the verification is considered successful.

[0381] The second verification module (not shown) is used for:

[0382] Obtain the fifth digest value and the sixth digest value stored by the blockchain node, wherein the fifth digest value corresponds to the first native integrator and the sixth digest value corresponds to the second native integrator;

[0383] Perform a digest operation on the first native integrator to obtain the seventh digest value, and perform a digest operation on the second native integrator to obtain the eighth digest value;

[0384] If the fifth digest value equals the seventh digest value, and the sixth digest value equals the eighth digest value, then the verification is successful.

[0385] The blockchain processing device 2200 also includes a processing unit (not shown), which is used for:

[0386] If the blockchain node is a full storage blockchain node, assign a storage sequence number to the object state data, and store the object state data, state data index and storage sequence number in the corresponding blockchain node.

[0387] Receive a query request for object status data, the query request containing the status data index;

[0388] The state data index determines that the blockchain node is a full-storage blockchain node, and the state data of the object is retrieved based on the state data index.

[0389] Referring to Figure 23, which is a partial structural block diagram of a terminal implementing the blockchain processing method of this disclosure, the terminal includes: a radio frequency (RF) circuit 2310, a memory 2315, an input unit 2330, a display unit 2340, a sensor 2350, an audio circuit 2360, a wireless fidelity (WiFi) module 2370, a processor 2380, and a power supply 2390, etc. Those skilled in the art will understand that the terminal structure shown in Figure 23 does not constitute a limitation on a mobile phone or computer, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0390] The RF circuit 2310 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 2380; in addition, it transmits uplink data to the base station.

[0391] The memory 2315 can be used to store software programs and modules. The processor 2380 executes various functional applications and data processing of the target terminal by running the software programs and modules stored in the memory 2315.

[0392] The input unit 2330 can be used to receive input numeric or character information, and to generate key signal inputs related to the settings and function control of the target terminal. Specifically, the input unit 2330 may include a touch panel 2331 and other input devices 2332.

[0393] Display unit 2340 can be used to display input or provided information, as well as various menus of the target terminal. Display unit 2340 may include display panel 2341.

[0394] Audio circuitry 2360, speaker 2361, and microphone 2362 provide an audio interface.

[0395] In this embodiment, the processor 2380 included in the terminal can execute the blockchain processing method of the previous embodiment.

[0396] The terminals disclosed in this embodiment include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The embodiments of this disclosure can be applied to various scenarios, including but not limited to data security, blockchain, data storage, and information technology.

[0397] Figure 24 is a partial structural block diagram of a server implementing the blockchain processing method of this disclosure. The server can vary significantly due to different configurations or performance, and may include at least one central processing unit (CPU) 2422 (e.g., at least one processor) and memory 2432, and at least one storage medium 2430 (e.g., at least one mass storage device) for storing application programs 2442 or data 2444. The memory 2432 and storage medium 2430 can be temporary or persistent storage. The program stored in the storage medium 2430 may include at least one module (not shown in the figure), and each module may include a series of instruction operations on the server. Furthermore, the CPU 2422 may be configured to communicate with the storage medium 2430 and execute the series of instruction operations in the storage medium 2430 on the server.

[0398] The server may also include at least one power supply 2423, at least one wired or wireless network interface 2450, at least one input / output interface 2458, and / or at least one operating system 2441, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0399] The central processing unit 2422 in the server can be used to execute the blockchain processing method of the present disclosure embodiments.

[0400] This disclosure also provides a computer-readable storage medium for storing program code for executing the blockchain processing methods of the foregoing embodiments.

[0401] This disclosure also provides a computer program product comprising a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the blockchain processing method described above.

[0402] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the foregoing drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0403] It should be understood that in this disclosure, "at least one item" means one or more, and "more than one" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0404] It should be understood that in the description of the embodiments disclosed herein, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0405] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0406] In this disclosure, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0407] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0408] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0409] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0410] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects.

[0411] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A blockchain processing method, characterized in that, The method, executed by blockchain nodes in a blockchain network, includes: In response to a block on-chain request, an object state list is determined based on the state update data corresponding to at least one transaction object in the block. The object state list includes object state data of the at least one transaction object, and the object state data has a state data index for referring to the transaction object. Based on the state data index, a full storage blockchain node for storing the object state data is determined in the blockchain network; In response to the fact that the blockchain node is different from the full storage blockchain node, the object state data is sent to the full storage blockchain node so that the full storage blockchain node stores the object state data, the state data index and the storage sequence number accordingly, and the storage sequence number is used to indicate the storage order of the object state data in the full storage blockchain node; Generate a first digest value for the object state data, and store the first digest value and the storage sequence number in the blockchain node; Receive a query request for the object's status data, the query request containing the status data index; Based on the state data index, the full storage blockchain node for storing the object state data is determined. The object state data and the storage sequence number are requested from the full storage blockchain node based on the state data index. The first digest value is queried in the blockchain node based on the storage sequence number, and the object state data is verified using the first digest value.

2. The method according to claim 1, characterized in that, The blockchain network includes multiple blockchain nodes, and each of the multiple blockchain nodes has a blockchain node identifier. The step of determining the full storage blockchain node for storing the object's state data in the blockchain network based on the state data index includes: Perform a modulo operation between the state data index and the number of the plurality of blockchain nodes to obtain the remainder; Based on the remainder, the blockchain node identifier of the full storage blockchain node is determined; The full storage blockchain node is determined based on the blockchain node identifier.

3. The method according to claim 2, characterized in that, The status data index includes a status data class index; The step of performing a modulo operation between the state data index and the number of the plurality of blockchain nodes to obtain the remainder includes: performing a modulo operation between the state data index and the number of the plurality of blockchain nodes to obtain the remainder.

4. The method according to claim 1, characterized in that, In response to the blockchain node being different from the full storage blockchain node, the object state data is sent to the full storage blockchain node so that the full storage blockchain node stores the object state data, the state data index, and the storage sequence number accordingly, including: In response to the fact that the blockchain node is different from the full storage blockchain node, the object state data is sent to the full storage blockchain node; If the historical object state data corresponding to the state data index has been stored on the full storage blockchain node, the historical object state data is updated with the object state data. If the historical object state data corresponding to the state data index is not stored on the full storage blockchain node, the storage sequence number is assigned to the object state data, and the object state data, the state data index and the storage sequence number are stored on the full storage blockchain node.

5. The method according to claim 1, characterized in that, The step of generating a first digest value for the object state data and storing the first digest value in the blockchain node in correspondence with the storage sequence number includes: If the blockchain node has already stored a second digest value of the historical object state data corresponding to the state data index, then the first digest value is generated and the second digest value is updated with the first digest value; If the blockchain node does not store the second digest value of the historical object state data corresponding to the state data index, then the first digest value is generated and stored in the blockchain node along with the storage sequence number.

6. The method according to claim 5, characterized in that, The step of generating the first digest value and updating the second digest value with the first digest value if the second digest value of the historical object state data corresponding to the state data index has already been stored on the blockchain node includes: If the second digest value of the historical object state data corresponding to the state data index has been stored on the blockchain node, then the historical object state data corresponding to the state data index is obtained from the full storage blockchain node. Perform a digest operation on the historical object state data to obtain a third digest value; If the second digest value is consistent with the third digest value, then the first digest value is generated, and the second digest value is updated with the first digest value.

7. The method according to claim 1, characterized in that, The step of generating the first digest value of the object state data includes: combining the object state data with the storage sequence number to obtain the original data; and performing a digest operation on the original data to obtain the first digest value. The step of verifying the object state data using the first digest value includes: receiving the object state data and the storage sequence number from the full storage blockchain node; combining the received object state data and the storage sequence number to obtain combined data; performing a digest operation on the combined data to obtain a fourth digest value; and verifying the object state data based on the first digest value and the fourth digest value.

8. The method according to claim 1, characterized in that, In response to the blockchain node being different from the full storage blockchain node, the object state data is sent to the full storage blockchain node so that the full storage blockchain node stores the object state data, the state data index, and the storage sequence number accordingly, including: In response to the fact that the blockchain node is different from the full storage blockchain node, the object state data is sent to the full storage blockchain node so that the full storage blockchain node combines the object state data, the storage sequence number, and the tag to obtain the original data of the object state data and stores the original data. The tag is the storage sequence number of the second adjacent object state data whose state data index follows the object state data. If there is no second adjacent object state data whose state data index follows the object state data, the tag is a first value. The process of generating the first digest value of the object state data includes: obtaining the original data from the full storage blockchain node, performing a digest operation on the original data, and obtaining the first digest value.

9. The method according to claim 7 or 8, characterized in that, After requesting the object state data and the storage sequence number from the full-storage blockchain node based on the state data index, the method further includes: If the object state data and the storage sequence number are not received from the full storage blockchain node, the first original data of the first adjacent object state data and the second original data of the second adjacent object state data are requested from the full storage blockchain node, wherein the state data index of the first adjacent object state data is placed before the state data index corresponding to the object state data, and the state data index of the second adjacent object state data is placed after the state data index corresponding to the object state data. Based on the first original data and the second original data, the reliability of the full-scale storage blockchain node is verified.

10. The method according to claim 9, characterized in that, The reliability verification of the full-scale storage blockchain node based on the first original data and the second original data includes: If the first raw data and the second raw data are received from the full storage blockchain node, and the tag in the first raw data is equal to the storage sequence number in the second raw data, then the reliability verification is determined to be successful. If only the first raw data is received from the full-store blockchain node, and the tag in the first raw data is the first value, then the reliability verification is determined to be successful. If only the second original data is received from the full-store blockchain node, and the object state data is determined based on the index list to be the object state data with the smallest state data index in an object state data block, then the reliability verification is determined to be passed. The object state data block is a plurality of object state data with consecutive state data indices in the index list, and the index list is a list of state data indices of object state data that have been written into the blockchain network.

11. The method according to claim 9, characterized in that, The reliability verification of the full-scale storage blockchain node based on the first original data and the second original data includes: If the state data index in the first original data, the state data index corresponding to the object state data, and the state data index in the second original data increase sequentially, then the reliability verification is determined to be successful.

12. The method according to claim 9, characterized in that, The reliability verification of the full-scale storage blockchain node based on the first original data and the second original data includes: Obtain the fifth digest value and the sixth digest value stored by the blockchain node, wherein the fifth digest value corresponds to the first original data and the sixth digest value corresponds to the second original data; Perform a digest operation on the first original data to obtain a seventh digest value, and perform a digest operation on the second original data to obtain an eighth digest value; If the fifth digest value is equal to the seventh digest value, and the sixth digest value is equal to the eighth digest value, then the reliability verification is determined to be successful.

13. The method according to claim 7 or 8, characterized in that, In response to the blockchain node being different from the full storage blockchain node, the method further includes sending the object state data to the full storage blockchain node so that the full storage blockchain node stores the object state data, the state data index, and the storage sequence number accordingly. The system requests the first original data of the state data of the first adjacent object and the second original data of the state data of the second adjacent object from the full storage blockchain node. The state data index of the first adjacent object is ranked before the state data index corresponding to the object state data in the full storage blockchain node, and the state data index of the second adjacent object is ranked after the state data index corresponding to the object state data in the full storage blockchain node. Verify the first raw data and the second raw data; If the verification passes, the marker in the first original data is changed to the storage sequence number of the object state data.

14. The method according to claim 13, characterized in that, The verification of the first raw data and the second raw data includes: If the tag in the first raw data is equal to the storage sequence number in the second raw data, then the verification is successful.

15. The method according to claim 13, characterized in that, The verification of the first raw data and the second raw data includes: If the state data index in the first original data, the state data index corresponding to the object state data, and the state data index in the second original data increase sequentially, then the verification is confirmed to be successful.

16. The method according to claim 13, characterized in that, The verification of the first raw data and the second raw data includes: Obtain the fifth digest value and the sixth digest value stored by the blockchain node, wherein the fifth digest value corresponds to the first original data and the sixth digest value corresponds to the second original data; Perform a digest operation on the first original data to obtain a seventh digest value, and perform a digest operation on the second original data to obtain an eighth digest value; If the fifth digest value is equal to the seventh digest value, and the sixth digest value is equal to the eighth digest value, then the verification is successful.

17. A blockchain processing device, characterized in that, Executed by blockchain nodes in a blockchain network, the device includes: An execution unit is configured to respond to a block's on-chain request and determine an object state list based on state update data corresponding to at least one transaction object in the block. The object state list includes object state data of the at least one transaction object, and the object state data has a state data index for referring to the transaction object. A determining unit is configured to determine, based on the state data index, a full-scale storage blockchain node in the blockchain network for storing the object's state data. A sending unit is configured to send the object state data to the full storage blockchain node in response to the fact that the blockchain node is different from the full storage blockchain node, so that the full storage blockchain node stores the object state data, the state data index and the storage sequence number accordingly, and the storage sequence number is used to indicate the storage order of the object state data in the full storage blockchain node; A generation unit is used to generate a first digest value of the object state data and store the first digest value and the storage sequence number in the blockchain node. A receiving unit is configured to receive a query request for the object's status data, the query request including the status data index; The verification unit is configured to determine the full storage blockchain node for storing the object state data based on the state data index, request the object state data and the storage sequence number from the full storage blockchain node based on the state data index, query the first digest value in the blockchain node based on the storage sequence number, and verify the object state data using the first digest value.

18. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the blockchain processing method according to any one of claims 1 to 16.

19. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the blockchain processing method according to any one of claims 1 to 16.

20. A computer program product comprising a computer program that is read and executed by a processor of an electronic device, causing the electronic device to perform the blockchain processing method according to any one of claims 1 to 16.

Images