Block chain processing method and device, electronic equipment and medium

Abstract

The invention provides a block chain processing method and device, electronic equipment and a medium. The block chain processing method comprises the steps of extracting a first total abstract from a first block head of a target block by utilizing a trusted execution environment, performing encryption processing based on the first total abstract to obtain a first ciphertext, and storing the first ciphertext in a ciphertext storage space; recording the target block on a block chain; in response to an acquisition request of a target terminal for a target transaction object state, acquiring a first ciphertext from the ciphertext storage space by using the trusted execution environment, and performing decryption processing based on the first ciphertext to obtain a recovered first total abstract; obtaining a target transaction object state and a second total abstract from the block chain accounting program; and in response to consistency of the first total abstract and the second total abstract, returning a target transaction object state to the target terminal. According to the embodiment of the invention, the encryption cost of the block chain node is reduced while the transaction object state query security is ensured. The embodiment of the invention can be applied to scenes such as cloud service object state query.

Description

Technical Field

[0001] This disclosure relates to the field of blockchain technology, and in particular to a blockchain processing method, apparatus, electronic device, and medium. Background Technology

[0002] In current blockchain cloud service systems, cloud service nodes act as blockchain nodes, providing Remote Procedure Call (RPC) interfaces to users who are not running blockchain nodes. This allows users to query the state of transaction-related objects within the blockchain. For example, when the blockchain records resource interaction transactions, users can query the resource status of each resource pool after the block transaction is executed via the RPC interface. Similarly, when the blockchain records IoT transactions, users can query the status of each IoT device (such as traffic lights) after the IoT transaction is executed via the RPC interface. These status queries are typically performed through the blockchain node's ledger program. Besides maintaining the blockchain, the ledger program also maintains the state of each transaction object. For instance, regarding the resource status of each resource pool, the ledger program maintains the resource status of each pool. Upon receiving a status query, the ledger program searches for the maintained transaction object status and returns the query result.

[0003] The transaction object states retrieved using the above methods are susceptible to modification by cloud service nodes, resulting in low security. While setting up a trusted execution environment (TEX) on the cloud service nodes can ensure the security of query results, this typically requires encrypting and storing the states of all transaction objects using the TEX for verifying the correctness of the results. Therefore, the encryption cost for cloud service providers is high. How to ensure the security of state queries while reducing the encryption cost for cloud service providers remains a challenge. Summary of the Invention

[0004] This disclosure provides a blockchain processing method, apparatus, electronic device, and medium that can reduce the encryption cost of blockchain nodes while ensuring the security of querying the state of transaction objects.

[0005] According to one aspect of this disclosure, a blockchain processing method is provided, executed by a target blockchain node, said target blockchain node having a trusted execution environment, a blockchain ledger program, and encrypted storage space, said blockchain processing method comprising:

[0006] In response to generating a target block to be recorded in the blockchain, the trusted execution environment is used to extract a first total digest from the first block header of the target block, and the first total digest is encrypted to obtain a first ciphertext, which is then stored in the ciphertext storage space. The target block includes one or more transactions, and the first total digest refers to a total digest of the state of each transaction object after the one or more transactions are executed.

[0007] Record the target block onto the blockchain;

[0008] In response to a request from the target terminal to obtain the state of the target transaction object after the execution of the one or more transactions, the trusted execution environment is used to obtain the first ciphertext from the ciphertext storage space, and decryption is performed based on the first ciphertext to obtain the recovered first total digest.

[0009] Obtain the state of the target transaction object and a second total summary from the blockchain ledger program, wherein the second total summary refers to the total summary of the state of each transaction object when the target blockchain node receives the acquisition request;

[0010] In response to the first total digest being consistent with the second total digest, the status of the target transaction object is returned to the target terminal.

[0011] According to one aspect of this disclosure, a blockchain processing apparatus is provided, executed on a target blockchain node, the target blockchain node having a trusted execution environment, a blockchain ledger program, and encrypted storage space, the blockchain processing apparatus comprising:

[0012] The first response unit is configured to respond to the generation of a target block to be recorded in the blockchain, and to extract a first total digest from the first block header of the target block using the trusted execution environment, and to perform encryption processing based on the first total digest to obtain a first ciphertext, which is then stored in the ciphertext storage space. The target block includes one or more transactions, and the first total digest refers to a total digest of the state of each transaction object after the one or more transactions are executed.

[0013] A recording unit is used to record the target block onto the blockchain;

[0014] The second response unit is used to respond to a request from the target terminal to obtain the state of the target transaction object after the execution of the one or more transactions, and to obtain the first ciphertext from the ciphertext storage space using the trusted execution environment, and to perform decryption processing based on the first ciphertext to obtain the recovered first total digest.

[0015] The acquisition unit is used to acquire the state of the target transaction object and a second total summary from the blockchain accounting program, wherein the second total summary refers to the total summary of the state of each transaction object when the target blockchain node receives the acquisition request;

[0016] The third response unit is used to return the status of the target transaction object to the target terminal in response to the first total digest being consistent with the second total digest.

[0017] Optionally, the first response unit is specifically used for:

[0018] Determine a summary of the state of each transaction object after all transactions in the target block have been executed;

[0019] Generate a first summary tree, wherein the bottom-level node of the first summary tree is the summary of the state of each transaction object, and the other nodes in the first summary tree, except for the bottom-level node, are generated by performing a summary operation on several adjacent nodes at the next lower level of the other nodes, until the first root node of the top level is generated.

[0020] Based on the first root node, the first overall summary is determined.

[0021] Optionally, the first response unit is specifically used for:

[0022] Obtain the first block header of the target block, and extract the third total digest from the first block header, wherein the third total digest is a total digest of the state of each transaction object in the target block before the transaction is executed;

[0023] Obtain the second block header of the previous block of the target block, and extract the fourth total digest from the second block header, wherein the fourth total digest is a total digest of the state of each transaction object after the execution of the transaction in the previous block;

[0024] If the third total digest is consistent with the fourth total digest, the first block header is determined to be valid, and the first total digest is extracted from the first block header.

[0025] Optionally, the first response unit is specifically used for:

[0026] In response to the third total digest being consistent with the fourth total digest, the consensus protocol version number is obtained from the first block header;

[0027] If the obtained consensus protocol version number belongs to a predetermined set of version numbers, the first block header is determined to be valid.

[0028] Optionally, the first response unit is specifically used for:

[0029] Obtain the first block identifier of the target block;

[0030] Integrate the first overall summary and the first block identifier to obtain the first integrated body;

[0031] The first integrated body is encrypted to obtain the first ciphertext;

[0032] The first ciphertext is stored in the ciphertext storage space in correspondence with the first block identifier.

[0033] Optionally, the second response unit is specifically used for:

[0034] Obtain the first block identifier from the acquisition request;

[0035] Retrieve the second ciphertext corresponding to the first block identifier from the ciphertext storage space;

[0036] The second ciphertext is decrypted to obtain the second integrated entity;

[0037] From the second consolidation, obtain the fifth overall summary and the third block identifier;

[0038] In response to the fact that the third block identifier is consistent with the first block identifier, the fifth total digest is determined to be the recovered first total digest.

[0039] Optionally, the first response unit is specifically used for:

[0040] The first overall summary and the first block identifier are interleaved according to the target interleaving rules to obtain the first integrated body;

[0041] The second response unit is specifically used for:

[0042] The second concatenation is de-interleaved according to the target interleaving rule to obtain the fifth total digest and the third block identifier.

[0043] Optionally, the first response unit is specifically used for:

[0044] Extract the target block type of the target block from the first block header;

[0045] The target interleaving rule is determined based on the target block type;

[0046] The first overall summary and the first block identifier are interleaved according to the determined target interleaving rules to obtain the first integrated body.

[0047] Optionally, the second response unit is specifically used for:

[0048] From the acquisition request, obtain the target block type of the target block;

[0049] The target interleaving rule is determined based on the target block type;

[0050] The second concatenation is de-interleaved according to the determined target interleaving rules to obtain the fifth total digest and the third block identifier.

[0051] Optionally, the first response unit is specifically used for:

[0052] Using the private key of the trusted execution environment, the first integrated body is symmetrically encrypted to obtain the first ciphertext;

[0053] The second response unit is specifically used for:

[0054] Using the private key, symmetric decryption is performed based on the second ciphertext to obtain the second integrated entity.

[0055] Optionally, the trusted execution environment has multiple private keys corresponding to multiple block types;

[0056] The first response unit is specifically used for:

[0057] Obtain the target block type of the target block from the first block header; use the private key corresponding to the target block type to perform symmetric encryption on the first integrated body to obtain the first ciphertext;

[0058] The second response unit is specifically used for:

[0059] The target block type is obtained from the acquisition request; the private key corresponding to the target block type is used to perform symmetric decryption based on the second ciphertext to obtain the second integrated body.

[0060] Optionally, the first response unit is specifically used for:

[0061] The first overall summary and the first block identifier are concatenated into a tuple using a predetermined delimiter to form the first integrated body;

[0062] The second response unit is specifically used for:

[0063] The second concatenation is parsed using the predetermined delimiter to obtain the fifth overall digest and the third block identifier.

[0064] Optionally, the blockchain processing device further includes a fourth response unit, which is specifically used for:

[0065] The system receives a composite retrieval request from the target terminal for the composite state of the target block, wherein the composite state is associated with the states of multiple target transaction objects; using the trusted execution environment, it retrieves the first ciphertext from the ciphertext storage space; decrypts the first ciphertext to obtain the recovered first total digest; retrieves the states of the multiple target transaction objects and a sixth total digest from the blockchain ledger program; in response to the first total digest being consistent with the sixth total digest, it generates the composite state using the retrieved states of the multiple target transaction objects and returns it to the target terminal, wherein the sixth total digest refers to the total digest of the states of each transaction object when the target blockchain node receives the composite retrieval request.

[0066] Optionally, the composite acquisition request includes a composite state function, which indicates the relationship between the composite state and the states of the plurality of target transaction objects;

[0067] The fourth response unit is specifically used for:

[0068] The composite state is obtained by substituting the acquired states of the multiple target transaction objects into the composite state function.

[0069] Optionally, the trusted execution environment has a built-in virtual machine;

[0070] The third response unit is specifically used for:

[0071] The first total summary is used as the target context of the built-in virtual machine, which compares the second total summary with the target context. In response to the second total summary matching the target context, the built-in virtual machine returns the target transaction object status to the target terminal.

[0072] Optionally, the third response unit is specifically used for:

[0073] The target transaction object state is signed using the private key of the trusted execution environment to obtain the target signature;

[0074] The target signature, along with the target transaction object status, is returned to the target terminal so that the target terminal can use the target signature to verify the target transaction object status.

[0075] Optionally, the blockchain processing device further includes a publishing unit, which is specifically used for:

[0076] Publish the public key of the trusted execution environment;

[0077] The target terminal is specifically used for:

[0078] Using the public key, the target signature is decrypted to obtain the decryption result;

[0079] A digest operation is performed on the state of the target transaction object using a predetermined digest algorithm to obtain a digest of the target transaction object's state.

[0080] If the decryption result matches the state digest of the target transaction object, the verification is successful.

[0081] Optionally, the acquisition unit is specifically used for:

[0082] Determine a summary of the state of each transaction object when the acquisition request is received;

[0083] A second summary tree is generated, wherein the bottommost node of the second summary tree is the summary of the state of each transaction object when the acquisition request is received, and the other nodes in the first summary tree, except for the bottommost node, are generated by performing a summary operation on a concatenation of several adjacent nodes at the next lower level of the other nodes, until the second root node at the top level is generated.

[0084] Based on the second root node, the second overall summary is determined.

[0085] 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.

[0086] 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.

[0087] According to one aspect of this disclosure, a computer program product is provided, comprising 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.

[0088] In this embodiment, when a target block is to be added to the blockchain, a trusted execution environment (TEU) extracts a first total digest from the first block header of the target block for verification during subsequent transaction object state queries. Since data cannot be persistently stored in the TEU, the TEU encrypts the first total digest to obtain a first ciphertext, which is then stored in the ciphertext storage space. Once the target blockchain is on-chain, if a request to retrieve the state of a target transaction object after one or more transactions have been executed is received, the TEU recovers the first total digest from the first ciphertext stored in the ciphertext storage space. Simultaneously, the TEU requests the target transaction object state and a second total digest from the blockchain ledger program. The first total digest refers to the total digest of the states of each transaction object after the execution of the target block's transactions, while the second total digest refers to the total digest of the states of each transaction object at the time the retrieval request is received. If the two are consistent, it indicates that the query result is accurate and has not been tampered with, and the target transaction object state can be returned, thus ensuring the security of transaction object state queries. Furthermore, the TEU does not store excessive transaction object states for state queries; it only encrypts the first total digest and stores it in the ciphertext storage space, reducing the encryption cost for blockchain nodes.

[0089] 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. Attached Figure Description

[0090] 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.

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

[0092] Figure 1B This is a system architecture diagram of the internal structure of a target blockchain node according to an embodiment of this disclosure;

[0093] Figure 2A This is a schematic diagram illustrating an application scenario where the blockchain processing method according to embodiments of this disclosure is applied to resource status query.

[0094] Figure 2B This is a schematic diagram illustrating an application scenario where the blockchain processing method according to embodiments of this disclosure is applied to IoT device status queries.

[0095] Figure 3 This is a main flowchart of a blockchain processing method according to embodiments of the present disclosure;

[0096] Figure 4 This is a schematic diagram illustrating the operations performed in response to a target block to be recorded in a blockchain, according to an embodiment of this disclosure.

[0097] Figure 5 This is a schematic diagram of the data structure of the target block according to an embodiment of the present disclosure;

[0098] Figure 6 This is a schematic diagram of the structure of the encrypted storage space according to an embodiment of the present disclosure;

[0099] Figure 7 This is an interactive diagram illustrating the operations performed in response to generating a target block to be recorded in the blockchain, according to an embodiment of the present disclosure, and the operations performed in response to a request from a target terminal to obtain the state of a target transaction object after one or more transactions have been executed.

[0100] Figure 8 This is a schematic diagram illustrating the operations performed according to an embodiment of the present disclosure in response to a request from a target terminal to obtain the state of a target transaction object after one or more transactions have been executed;

[0101] Figure 9 This is a flowchart illustrating the generation of a first general summary using a blockchain ledger procedure according to embodiments of this disclosure;

[0102] Figure 10 This is a schematic diagram of the structure of a first abstract tree according to an embodiment of the present disclosure;

[0103] Figure 11 This is a flowchart illustrating the extraction of a first total digest from the first block header of a target block according to an embodiment of the present disclosure;

[0104] Figure 12 This is a schematic diagram illustrating the determination of the validity of the first block header when the third general digest and the fourth general digest are consistent, according to an embodiment of this disclosure.

[0105] Figure 13 This is a flowchart illustrating the determination of the validity of the first block header when the third general digest and the fourth general digest are consistent, according to embodiments of this disclosure.

[0106] Figure 14 This is a schematic diagram of the structure of the target block according to an embodiment of the present disclosure;

[0107] Figure 15 This is a flowchart illustrating the encryption process based on a first general digest according to an embodiment of the present disclosure, resulting in a first ciphertext, which is then stored in a ciphertext storage space.

[0108] Figure 16This is an interactive schematic diagram illustrating the encryption process based on a first general digest according to an embodiment of the present disclosure, resulting in a first ciphertext, which is then stored in a ciphertext storage space.

[0109] Figure 17 This is a schematic diagram illustrating the storage of a first ciphertext corresponding to a first block identifier in a ciphertext storage space according to an embodiment of the present disclosure;

[0110] Figure 18 This is a flowchart of the operations performed according to embodiments of the present disclosure in response to a composite acquisition request from a target terminal for the composite state of a target block;

[0111] Figure 19 This is an interactive diagram illustrating an interaction in response to a target terminal's request to acquire the composite state of a target block, according to an embodiment of this disclosure.

[0112] Figure 20 This is a flowchart illustrating how, according to an embodiment of the present disclosure, a first ciphertext is obtained from a ciphertext storage space, and decryption is performed based on the first ciphertext to obtain a recovered first total digest.

[0113] Figure 21 This is a schematic diagram illustrating the process of retrieving the second ciphertext corresponding to the first block identifier from the ciphertext storage space according to an embodiment of the present disclosure.

[0114] Figure 22 This is an interactive schematic diagram illustrating the process of obtaining first ciphertext from a ciphertext storage space and performing decryption processing based on the first ciphertext to obtain a recovered first total digest, according to an embodiment of this disclosure.

[0115] Figure 23 This is a flowchart illustrating how a first general digest and a first block identifier are interleaved according to a target interleaving rule, and how a second concatenation is deinterleaved according to the target interleaving rule, based on embodiments of this disclosure.

[0116] Figure 24 This is a flowchart illustrating how a first general digest and a first block identifier are interleaved according to a target interleaving rule to obtain a first integrated body, based on an embodiment of this disclosure.

[0117] Figure 25A This is a schematic diagram of interleaving a first general digest and a first block identifier according to a defined target interleaving rule to obtain a first integrated body, based on an embodiment of the present disclosure;

[0118] Figure 25B This is a schematic diagram of interleaving a first general digest and a first block identifier according to a determined target interleaving rule, based on another embodiment of this disclosure, to obtain a first integrated body;

[0119] Figure 26This is a flowchart illustrating the process of deinterleaving a second concatenation according to a target interleaving rule to obtain a fifth overall digest and a third block identifier, based on an embodiment of this disclosure.

[0120] Figure 27A This is a schematic diagram illustrating the process of deinterleaving a second concatenation according to a defined target interleaving rule, based on an embodiment of the present disclosure, to obtain a fifth general digest and a third block identifier;

[0121] Figure 27B This is a schematic diagram illustrating the process of deinterleaving a second concatenation according to a defined target interleaving rule, based on another embodiment of this disclosure, to obtain a fifth general summary and a third block identifier;

[0122] Figure 28 This is a flowchart illustrating the determination of a first ciphertext and a second integrated body according to an embodiment of the present disclosure;

[0123] Figure 29 This is a flowchart illustrating the determination of a first ciphertext and a second integrated body according to another embodiment of this disclosure;

[0124] Figure 30 This is a schematic diagram illustrating how a first ciphertext is obtained by symmetric encryption of a first integrated body using the private key corresponding to the target block type, according to an embodiment of this disclosure.

[0125] Figure 31 This is a flowchart illustrating the process of determining a first integrator and obtaining a fifth general summary and a third block identifier according to embodiments of this disclosure.

[0126] Figure 32 This is a schematic diagram of determining a first integrated body according to an embodiment of the present disclosure;

[0127] Figure 33 This is a schematic diagram illustrating the acquisition of the fifth general digest and the third block identifier according to embodiments of this disclosure;

[0128] Figure 34 This is a flowchart illustrating the process of obtaining a second general summary using a blockchain ledger procedure according to an embodiment of this disclosure;

[0129] Figure 35 This is a schematic diagram of the structure of a second abstract tree according to an embodiment of the present disclosure;

[0130] Figure 36 This is a flowchart illustrating the process of returning the status of a target transaction object to a target terminal according to an embodiment of this disclosure;

[0131] Figure 37 This is a system architecture diagram of a target blockchain node with a built-in virtual machine, according to an embodiment of this disclosure;

[0132] Figure 38This is a flowchart illustrating the process of returning the status of a target transaction object to a target terminal according to an embodiment of this disclosure;

[0133] Figure 39 This is an interactive schematic diagram illustrating the process of returning the status of a target transaction object to a target terminal according to an embodiment of this disclosure;

[0134] Figure 40 This is a flowchart illustrating how a target terminal can decrypt a target signature using a public key disclosed in an embodiment of this disclosure.

[0135] Figure 41 This is a block diagram of a blockchain processing apparatus according to embodiments of the present disclosure;

[0136] Figure 42 This is a terminal structure diagram of performing a blockchain processing method according to embodiments of this disclosure;

[0137] Figure 43 This is a server architecture diagram for performing a blockchain processing method according to embodiments of this disclosure. Detailed Implementation

[0138] 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.

[0139] Before providing a further detailed description of the embodiments of this disclosure, the terms and concepts used in these embodiments are explained, and they are subject to the following interpretations:

[0140] Blockchain: A distributed ledger technology in the field of information technology. It generally consists of consensus, transaction blocks and state data storage, cryptographic identity security and other components. Because the ledger is stored in a distributed manner and the blocks are agreed upon, it has the characteristics of being immutable, traceable and jointly maintained.

[0141] Consensus Algorithm: The consensus algorithm process generally consists of three stages: block creation, block verification, and block submission. According to the consensus protocol, a master node is selected from the participating nodes to create a new block (defined as the node that produces a valid block in each round of consensus); then, the new block is independently verified by other participating nodes; the verified block is submitted to the local blockchain by the node, achieving consensus on the latest block height; this completes the consensus process and initiates the next round of consensus.

[0142] Remote Procedure Call (RPC) is a method of inter-process communication that allows programs to call procedures or functions between different computers without requiring programmers to explicitly handle the underlying network technology. The basic idea of ​​RPC is to make remote procedure calls appear as local procedure calls by hiding the communication details through client-side and server-side stubs.

[0143] Status: refers to the data operated on and stored by blockchain smart contracts, such as product bills, logistics and other information stored in the contract.

[0144] In current blockchain cloud service systems, cloud service nodes act as blockchain nodes, providing Remote Procedure Call (RPC) interfaces to users who are not running blockchain nodes. This allows users to query the state of objects related to transactions within the blockchain. For example, when the blockchain records resource interaction transactions, users can query the resource status of each resource pool after the block transaction is executed via the RPC interface. Similarly, when the blockchain records IoT transactions, users can query the status of each IoT device (such as traffic lights) after the IoT transaction is executed via the RPC interface. These status queries are typically performed through the blockchain node's ledger program. Besides maintaining the blockchain, the blockchain ledger program also maintains the state of each transaction object. For instance, regarding the resource status of each resource pool, the blockchain ledger program maintains the resource status of each pool. Upon receiving a status query, the blockchain ledger program looks up the maintained transaction object status and returns the query result.

[0145] The transaction object states retrieved using the above methods are susceptible to modification by cloud service nodes, resulting in low security. While setting up a trusted execution environment (TEX) on the cloud service nodes can ensure the security of query results, this typically requires encrypting and storing the states of all transaction objects using the TEX for verifying the correctness of the results. Therefore, the encryption cost for cloud service providers is high. How to ensure the security of state queries while reducing the encryption cost for cloud service providers remains a challenge.

[0146] Based on this, embodiments of this disclosure provide a blockchain processing method, apparatus, electronic device, and medium. The blockchain processing method provided by these embodiments can, upon receiving a request from a target terminal to retrieve the state of a target transaction object after one or more transactions have been executed, utilize a trusted execution environment to recover a first total digest from first ciphertext stored in the ciphertext storage space. Simultaneously, it requests the target transaction object state and a second total digest from the blockchain ledger program. If the first and second total digests are consistent, it indicates that the total digest of the state of each transaction object after the execution of the target block's transactions is consistent with the total digest of the state of each transaction object at the time the retrieval request is received, and the query result is accurate. By comparing the first and second total digests, the security of transaction object state queries is ensured. Furthermore, the trusted execution environment does not store excessive transaction object states for state queries; it only encrypts the first total digest and stores it in the ciphertext storage space, reducing the encryption cost of blockchain nodes.

[0147] System architecture and scenario description of the embodiments disclosed herein

[0148] Figure 1A This is a system architecture diagram of a blockchain processing method applied according to embodiments of the present disclosure, which is incorporated herein by reference. Figure 1A To explain the blockchain processing method entirely on the server: A blockchain network is a network composed of blockchain nodes. Figure 1A The blockchain network in the diagram includes blockchain node 1, blockchain node 2, blockchain node 3, and blockchain node 4. It can be understood that each blockchain node here is a server, and multiple blockchain nodes are interconnected. For example, during the consensus process, blockchain node 1 packages transactions 1, 2, 3, 4, and 5 into block 1 and broadcasts it to blockchain nodes 2, 3, and 4 for independent verification. If blockchain nodes 2, 3, and 4 all successfully verify block 1, the blockchain consensus process is complete. Blockchain nodes 1-5 then record block 1 on their respective maintained blockchains.

[0149] Furthermore, referring to Figure 1B , Figure 1B This is a system architecture diagram of the internal structure of a target blockchain node according to an embodiment of this disclosure. It is understood that a target blockchain node refers to a blockchain node that provides a remote procedure call interface to a user, and the target blockchain node can be any blockchain node participating in consensus within the blockchain network. The target blockchain node internally includes a trusted execution environment, encrypted storage space, and a blockchain ledger program. These modules are described in detail here:

[0150] Trusted Execution Environment (TEE): A TEE provides an isolated and secure environment within the target blockchain node through hardware isolation, protecting data computation and operations from unauthorized access and tampering. Without compromising the hardware, attackers cannot directly read highly secure data and system keys within the TEE, thus ensuring data confidentiality. Furthermore, attackers cannot bypass the fixed hardware logic and hardware-level tamper detection, ensuring that the system's operation is not maliciously altered.

[0151] Ciphertext storage space: Ciphertext storage space refers to the space within the target blockchain node used to store ciphertext. Ciphertext refers to the information obtained by encrypting a portion of the data in a block read by the blockchain node. By encrypting a portion of the data in a block read by the blockchain node, the security of that data can be ensured.

[0152] Blockchain ledger program: The blockchain ledger program not only maintains the blockchain itself, but also the state of each transaction object within it. Once multiple blockchain nodes in the network reach a consensus on a new block, this new block is added to the blockchain. As new blocks are added, all blockchain nodes update the state of each transaction object maintained by the blockchain ledger program to ensure the real-time performance of the blockchain.

[0153] The blockchain processing method of this disclosure can be applied in various scenarios, such as cloud service resource pool status query and cloud service IoT device status query. The application scenarios of the blockchain processing method are described below:

[0154] (I) Cloud Service Resource Pool Status Inquiry

[0155] Reference Figure 2A In this blockchain network, blockchain nodes can be cloud service nodes, and these cloud service nodes are operated and maintained by cloud service providers. In the case of cloud service resource pool queries, the blockchain processing method of this disclosure is used to record resource interaction transactions. Assuming blockchain node 1 in the blockchain network is a cloud service node, users can query the number of resources in the resource pool through the remote procedure call interface provided by blockchain node 1. In one embodiment, when a user requests a query for the number of resources in resource pool 1, after receiving the cloud service object query request from the user, blockchain node 1 will respond by reading the number of resources in each resource pool maintained by the blockchain ledger program, thereby determining the number of resources in resource pool 1. After determining the number of resources in resource pool 1, blockchain node 1 returns it to the user.

[0156] (II) Cloud Service IoT Device Status Inquiry

[0157] Reference Figure 2B In this disclosure, the blockchain processing method, when applied to cloud service IoT device queries, uses blockchain to record IoT transactions. In one embodiment, the IoT device is a camera used to acquire real-time traffic conditions, and blockchain node 1 in the blockchain network is a cloud service node. Users can query the traffic conditions acquired by the IoT device through the remote procedure call interface provided by blockchain node 1. Assuming a user requests a query for the traffic conditions acquired by IoT device 1, after receiving the cloud service object query request from the user, blockchain node 1 will respond by reading the traffic conditions acquired by the IoT device maintained by the blockchain ledger program, thereby determining the traffic conditions acquired by IoT device 1. After determining the traffic conditions acquired by IoT device 1, blockchain node 1 returns them to the user.

[0158] It should be understood that the above description only illustrates some application scenarios of this disclosure. The business scenarios to which this disclosure can be applied may include, but are not limited to, the specific scenarios mentioned above.

[0159] General Description of Embodiments in this Disclosure

[0160] In related technologies, the status of transaction objects queried by users through remote procedure call interfaces is easily modified by cloud service nodes, resulting in low security. If a trusted execution environment is set up in the cloud service node to ensure the security of the query results, the encryption cost for cloud service providers is high because this typically requires encrypting and storing the status of all transaction objects using the trusted execution environment to verify the correctness of the query results. Therefore, how to ensure the security of status queries while reducing the encryption cost for cloud service providers has become a challenge.

[0161] Some embodiments of this disclosure provide a blockchain processing method, apparatus, electronic device, and medium. Blockchain processing broadly refers to data processing used in the process of recording blocks on a blockchain and querying transactions within those recorded blocks.

[0162] According to one embodiment of this disclosure, a blockchain processing method is provided. This method can be applied to, for example... Figure 2A Cloud service resource pool status query Figure 2B Application scenarios include cloud services for querying the status of IoT devices.

[0163] like Figure 3 As shown, a blockchain processing method according to an embodiment of this disclosure is executed by a target blockchain node, which has a trusted execution environment, a blockchain ledger program, and encrypted storage space. The blockchain processing method includes:

[0164] Step 310: In response to generating a target block to be recorded in the blockchain, using a trusted execution environment, extract the first total digest from the first block header of the target block, perform encryption processing based on the first total digest to obtain the first ciphertext, and store it in the ciphertext storage space. The target block includes one or more transactions, and the first total digest refers to the total digest of the state of each transaction object after one or more transactions are executed.

[0165] Step 320: Record the target block on the blockchain;

[0166] Step 330: In response to the target terminal's request to obtain the state of the target transaction object after one or more transactions have been executed, the trusted execution environment is used to obtain the first ciphertext from the ciphertext storage space, and the first ciphertext is decrypted to obtain the recovered first total digest.

[0167] Step 340: Obtain the state of the target transaction object and the second total digest from the blockchain ledger program, wherein the second total digest refers to the total digest of the state of each transaction object when the target blockchain node receives the acquisition request;

[0168] Step 350: In response to the consistency between the first and second general digests, return the target transaction object status to the target terminal.

[0169] The following is a brief description of steps 310-350 above.

[0170] In step 310, in response to generating a target block to be recorded in the blockchain, a first total digest is extracted from the first block header of the target block using a trusted execution environment, and encryption processing is performed based on the first total digest to obtain the first ciphertext, which is then stored in the ciphertext storage space. The target block includes one or more transactions, and the first total digest refers to the total digest of the state of each transaction object after the execution of one or more transactions.

[0171] According to embodiments of this disclosure, a target blockchain node refers to a blockchain node that can provide a remote procedure call interface to users who are not running a blockchain node. The target blockchain node can be any blockchain node participating in consensus within the blockchain network, and each target blockchain node has a trusted execution environment, a blockchain ledger program, and encrypted storage space. Since the trusted execution environment, blockchain ledger program, and encrypted storage space have already been described above, the functions of these three modules will not be repeated here. For example, refer to... Figure 4Assume the blockchain network includes three target blockchain nodes: target blockchain node A, target blockchain node B, and target blockchain node C. Target blockchain node A includes a trusted execution environment A, a blockchain ledger program A, and a encrypted storage space A; target blockchain node B includes a trusted execution environment B, a blockchain ledger program B, and an encrypted storage space B; and target blockchain node C includes a trusted execution environment C, a blockchain ledger program C, and an encrypted storage space C.

[0172] Reference Figure 4 It is understandable that, during the process of participating in block consensus, for a target block to be recorded on the blockchain, the target blockchain node can extract the first block header of the target block through the blockchain accounting program, and use a trusted execution environment to extract the first total digest from the first block header of the target block. Here, the target block refers to a newly added block that has not yet been recorded on the blockchain. Blockchain nodes in the blockchain network (including the target blockchain node) can verify the validity of the target block to determine whether to record it on the blockchain. Further, refer to... Figure 5 The target block includes a block body and a first block header. The block body stores one or more transactions and other related data in the target block. The first block header of the target block contains information such as the first total digest of the target block, the digest value of the previous block of the target block, the time when the target block was generated, and the consensus protocol when the target block was produced.

[0173] Specifically, the blockchain accounting process can extract the header information of the deserialized target block, i.e., the first block header, by deserializing the target block. For example, suppose the target block is a Block. N The first block header can be extracted by deserializing the target block using the following function:

[0174] Header N =GET_HEADER(Block) N );

[0175] Among them, Header N This represents the first block header; GET_HEADER represents the function that deserializes the target block and extracts the header information of the deserialized target block.

[0176] According to embodiments of this disclosure, the first total digest refers to a total digest of the states of each transaction object after one or more transactions of the target block have been executed. More specifically, the first total digest generally refers to the total hash value calculated by hashing the states of each transaction object after the execution of transactions in the target block, based on the hash values ​​of the states of each transaction object after the execution of transactions in the target block. Here, hashing is the process of transforming an input of arbitrary length into an output of fixed length using a hash algorithm.

[0177] It's understandable that a transaction is the basic unit that makes up a block; it's a piece of event data that needs to be recorded on the blockchain. For example, "Traffic congestion occurred at intersection A on October 28, 2024, at 12:00:03" is a piece of event data that needs to be recorded on the traffic data blockchain in the urban traffic IoT; "Transferring 15 resources from resource pool A to resource pool B" is a piece of event data that needs to be recorded on the resource interaction blockchain. A transaction object refers to the object that the transaction targets. For example, "Traffic congestion occurred at intersection A" targets "intersection A"; "Transferring 15 resources from resource pool A to resource pool B" targets both "resource pool A" and "resource pool B". The transaction object state refers to the current state of the transaction object. For example, after the transaction "Transferring 15 resources from resource pool A to resource pool B" is executed, the number of resources in resource pool A becomes 85, and the number of resources in resource pool B becomes 50. Therefore, "Resource pool A 85, resource pool B 50" is the transaction object state after the transaction is executed.

[0178] According to embodiments of this disclosure, referring to Figure 4 After the target blockchain node extracts the first total digest from the first block header of the target block using a trusted execution environment, it encrypts the first total digest to obtain the first ciphertext. The first ciphertext refers to the data obtained after encrypting the first total digest using the trusted execution environment. By utilizing a trusted execution environment, the first total digest can be encrypted under completely isolated external conditions, ensuring the reliability of the encryption. Moreover, the embodiments of this disclosure only require encrypting the first total digest of the target block, without needing to encrypt all the data in the target block, reducing the encryption cost for the target blockchain node.

[0179] Understandably, since the trusted execution environment (TEX) is a CPU (Central Processing Unit), and CPUs lack post-power-off storage capabilities, once the CPU loses power, the data stored on it is erased. Therefore, the TEX lacks persistent storage capabilities and only supports encryption of the first total digest. Thus, after the trusted hardware encrypts the first total digest to obtain the first ciphertext, it is necessary to store the first ciphertext in the ciphertext storage space of the target blockchain node. For example, as... Figure 6As shown, the ciphertext storage space stores first ciphertext A, first ciphertext B, first ciphertext C, and first ciphertext D, etc., all of which are submitted by the trusted execution environment of the target blockchain node.

[0180] On the other hand, the reason why the first total digest must be encrypted before being stored in the ciphertext storage space is that the ciphertext storage space is an external module relative to the trusted execution environment and lacks trustworthiness. If the plaintext of the first total digest is directly stored in the trusted execution environment, there is a risk that the first total digest may be tampered with. The embodiments of this disclosure, by encrypting the first total digest to form the first ciphertext for storage in the ciphertext storage space, effectively prevent the cloud service provider operating the target blockchain node from tampering with the first total digest, thereby improving the security of the blockchain.

[0181] In step 320, the target block is recorded on the blockchain.

[0182] According to embodiments of this disclosure, after multiple blockchain nodes in the blockchain network successfully reach a consensus on a target block, the target block can then be recorded on the blockchain. Recording the target block on the blockchain essentially means recording one or more transactions contained within the target block on the blockchain network to ensure the immutability and transparency of each transaction contained in the target block. For example, refer to... Figure 7 Assume that when the target blockchain node obtains the target block to be recorded on the blockchain, the blockchain includes block 1, block 2, block 3, and block 4. After the target blockchain node successfully reaches consensus on the target block, the target block can be recorded on the blockchain. The updated blockchain includes block 1, block 2, block 3, block 4, and the target block.

[0183] In step 330, in response to the target terminal's request to obtain the state of the target transaction object after one or more transactions have been executed, the trusted execution environment is used to obtain the first ciphertext from the ciphertext storage space, and the first ciphertext is decrypted to obtain the recovered first total digest.

[0184] According to embodiments of this disclosure, the target terminal refers to a terminal used to invoke the remote procedure call interface provided by the target blockchain node. The retrieval request is issued by the target terminal to request the target blockchain node to obtain the state of a target transaction object after one or more transactions have been executed. The state of the target transaction object refers to the state of a specific transaction object that the target terminal needs to obtain after one or more transactions in the target block have been executed. Generally, to ensure the real-time nature of the transaction object state, the one or more transactions targeted by the target terminal are those contained in a newly added block on the current blockchain. For example, suppose the latest added target block on the current blockchain is target block 1, and target block 1 records multiple transactions concerning resource interactions between various resource pools. After the multiple transactions in target block 1 are executed, the number of resources in resource pools A, B, C, etc., will change. At this time, the retrieval request sent by the target terminal may be a request to obtain the number of resources in resource pool A after the transactions in target block 1 have been executed; in this case, the state of the target transaction object is the number of resources in resource pool A.

[0185] In step 340, the state of the target transaction object and the second total digest are obtained from the blockchain ledger program, wherein the second total digest refers to the total digest of the state of each transaction object when the target blockchain node receives the acquisition request.

[0186] Understandably, since the blockchain node's ledger program maintains the state of each transaction object in the blockchain, a target blockchain node can obtain the state of a target transaction object through the ledger program. However, because the ledger program is an external program relative to the trusted execution environment, the state of each transaction object maintained by the ledger program is not trustworthy to the trusted execution environment. To verify the trustworthiness of the target transaction object state returned by the ledger program, the ledger program returns a second summary to the trusted execution environment along with the target transaction object state, allowing the trusted execution environment to verify the trustworthiness of the target transaction object state based on the second summary. The second summary refers to the total summary of the states of each transaction object when the target blockchain node receives the request. In one embodiment, the second summary generally refers to the total hash value calculated based on the hash values ​​of the states of each transaction object when the request is received.

[0187] In step 350, in response to the first general summary being consistent with the second general summary, the target transaction object status is returned to the target terminal.

[0188] According to embodiments of this disclosure, the first total digest refers to the total digest of the states of each transaction object after one or more transactions in the target block have been executed, and the second total digest refers to the total digest of the states of each transaction object when the retrieval request is received. Since the one or more transactions targeted by the retrieval request sent by the target terminal are generally transactions included in newly added blocks on the current blockchain, the consistency between the first and second total digests indicates that the state of the target transaction object returned by the blockchain accounting program is trustworthy. Based on this, the trusted execution environment can verify the trustworthiness of the target transaction object state by comparing the first and second total digests. However, because the trusted execution environment itself does not store the first total digest, but rather it is encrypted into a first ciphertext and stored in the ciphertext storage space, after receiving the retrieval request sent by the target terminal, the target blockchain node will first use the trusted execution environment to retrieve the required first ciphertext from the ciphertext storage space, such as... Figure 8 As shown. Since the first ciphertext is in encrypted format and cannot be used directly, the Trusted Execution Environment (TEE) will decrypt it to obtain the recovered first total digest. After recovering the first total digest, the TEE can call the blockchain ledger program to obtain the target transaction object state and the second total digest, and verify the trustworthiness of the blockchain ledger program by comparing the first and second total digests. If the first and second total digests match, the TEE returns the target transaction object state to the target terminal in response to the match.

[0189] It is understandable that the reason the target blockchain node in this embodiment extracts the first total digest of the target block before receiving the acquisition request, rather than extracting it in real time after receiving the acquisition request, is because when the target blockchain node obtains the target block to be recorded on the blockchain in advance, the first block header extracted from the target block by the blockchain accounting program is trustworthy (because at this time, the cloud service provider operating the target blockchain node has no incentive to tamper with the first block header). With the first block header being trustworthy, the first total digest extracted from the first block header by the trusted execution environment and the first ciphertext obtained after encrypting the first total digest are also trustworthy. However, if the first total digest of the target block is extracted in real time after receiving the acquisition request, the cloud service provider operating the target blockchain node has an incentive to tamper with the first block header; therefore, the first total digest extracted from the first block header lacks trustworthiness. Thus, this embodiment of the invention ensures the security of transaction object state queries by extracting the first total digest of the target block before receiving the acquisition request.

[0190] In the embodiments of steps 310 to 350 above, when the target block is to be added to the blockchain, a first total digest is extracted from the first block header of the target block using a trusted execution environment (TEA) for verification of the transaction object status query. Since data cannot be persistently stored in the TEA, the TEA encrypts the first total digest to obtain a first ciphertext, which is stored in the ciphertext storage space. When the target blockchain is added to the blockchain, if a request to retrieve the status of the target transaction object after one or more transactions have been executed is received, the TEA uses the TEA to recover the first total digest from the first ciphertext stored in the ciphertext storage space. Simultaneously, the TEA requests the target transaction object status and a second total digest from the blockchain ledger program. The first total digest refers to the total digest of the status of each transaction object after the execution of the target block's transactions, and the second total digest refers to the total digest of the status of each transaction object when the retrieval request is received. If the two are consistent, it indicates that the query result is accurate and has not been tampered with, and the target transaction object status can be returned, thus ensuring the security of the transaction object status query. Furthermore, the TEA does not store excessive transaction object status for status queries; it only encrypts the first total digest and stores it in the ciphertext storage space, reducing the encryption cost of the blockchain nodes.

[0191] The above is a general description of steps 310 to 350. The specific implementation process of steps 310 to 350 is described in detail below.

[0192] Detailed description of step 310

[0193] Step 310: In response to generating a target block to be recorded in the blockchain, using a trusted execution environment, extract a first total digest from the first block header of the target block, perform encryption processing based on the first total digest to obtain the first ciphertext, and store it in the ciphertext storage space. The target block includes one or more transactions, and the first total digest refers to the total digest of the state of each transaction object after the execution of one or more transactions.

[0194] In one embodiment, reference is made to Figure 9 The first summary of step 310 is generated by the blockchain ledger program in the following way:

[0195] Step 910: Determine a summary of the state of each transaction object after all transactions in the target block have been executed;

[0196] Step 920: Generate the first summary tree, wherein the bottom-level node of the first summary tree is a summary of the state of each transaction object. Other nodes in the first summary tree, except for the bottom-level node, are generated by performing a summary operation on several adjacent nodes at the next lower level of other nodes, until the first root node at the top level is generated.

[0197] Step 930: Determine the first general summary based on the first root node.

[0198] Steps 910 to 930 are described in detail below:

[0199] In step 910, a summary of the state of each transaction object after all transactions in the target block have been executed is determined.

[0200] Understandably, an example of a digest is a hash value. In this case, the digest of a transaction object's state refers to the hash value obtained by hashing the transaction object's state. For instance, suppose there is only one transaction in the target block: "Transfer 100 resources from resource pool A to resource pool B". After this transaction is executed, resource pool A has 55 resources, and resource pool B has 150 resources. Then, the digest of the transaction object's state for resource pool A is the hash value obtained by hashing 55, and the digest of the transaction object's state for resource pool B is the hash value obtained by hashing 150.

[0201] According to embodiments of this disclosure, when a blockchain ledger program reads a target block, it first needs to determine a summary of the state of each transaction object after all transactions contained in the target block have been executed. For example, refer to... Figure 10 Assume the target block contains transactions 1, 2, and 3. After transactions 1, 2, and 3 are completed, we obtain transaction object states 1, 2, 3, and 4 (e.g., the number of resources in resource pool 1, resource pool 2, resource pool 3, and resource pool 4). Then, we perform hash calculations on transaction object states 1, 2, 3, and 4 respectively, yielding transaction object state digest values ​​1, 2, 3, and 4. Here, transaction object state digest value 1 is the digest of transaction object state 1, 2 is the digest of transaction object state 2, 3 is the digest of transaction object state 3, and 4 is the digest of transaction object state 4.

[0202] In step 920, a first summary tree is generated, wherein the bottom-level node of the first summary tree is a summary of the state of each transaction object. Other nodes in the first summary tree, except for the bottom-level node, are generated by performing summary operations on several adjacent nodes at the next lower level of other nodes until the first root node at the top level is generated.

[0203] According to embodiments of this disclosure, a first digest tree refers to a tree-like data structure where the digest of the state of each transaction object after all transactions in the target block have been executed is used as the lowest-level node. In the first digest tree, nodes other than the lowest-level node are generated by concatenating several adjacent nodes at the next lower level and performing digest operations. In one embodiment, the digest operation refers to hash calculation using a hash function. The first root node refers to the root node in the first digest tree, which can be understood as the final digest obtained by concatenating the digests of the states of all transaction objects after all transactions in the target block have been executed.

[0204] For example, refer to Figure 10 Transaction object state summary values ​​1 and 2 are adjacent, and transaction object state summary values ​​3 and 4 are adjacent. After performing a summary operation on transaction object state summary values ​​1 and 2, transaction object state summary value 12 is obtained. After performing a summary operation on transaction object state summary values ​​3 and 4, transaction object state summary value 34 is obtained. At this point, transaction object state summary values ​​12 and 34 are adjacent. After performing a summary operation on transaction object state summary values ​​12 and 34, transaction object state summary value 1234 is obtained. It can be understood that transaction object state summary value 1234 is the final summary obtained after cascading transaction object state summary values ​​1, 2, 3, and 4, and transaction object state summary value 1234 is the first root node of the first summary tree.

[0205] Furthermore, the integrity of the state of each transaction object can be verified through the first root node of the first digest tree. In the first digest tree, modification of the digest of any node will cause changes to the digest of the first root node and the digests of the nodes above the node whose digest was modified. By tracing the nodes in the first digest tree where digests have changed, the node whose digest was initially modified can be quickly located. For example, suppose... Figure 10 When the state 1 of a transaction object is modified, not only will the transaction object state summary value 1 change, but the transaction object state summary values ​​12 and 1234 will also change. Starting from the first root node of the first summary tree, tracing back to the node where the summary has changed, the transaction object state summary value 1 can be quickly located, thus confirming that the transaction object state 1 has been modified.

[0206] In step 930, a first general summary is determined based on the first root node.

[0207] According to embodiments of this disclosure, the first root node in the first summary tree is the first total summary. For example... Figure 10 As shown, the first root node of the first summary tree is the transaction object state summary value 1234, and the transaction object state summary value 1234 is the first total summary.

[0208] The blockchain ledger program in the embodiments of steps 910 to 930 described above can construct the bottom-level node of the first digest tree based on the digest of the state of each transaction object after all transactions have been executed, and perform concatenation and digest operations on the bottom-level nodes of the first digest tree until the top-level first root node is generated, thus obtaining the first digest tree. Based on the first root node of the first digest tree, the first total digest can be determined. Since any modification to the digest of any node in the first digest tree will cause a change in the first total digest, the state of each transaction object in the target block can be efficiently verified based on the first total digest, verifying whether the state of any transaction object in the target block has changed or been modified.

[0209] In one embodiment, reference is made to Figure 11 Step 310 includes:

[0210] Step 1110: Obtain the first block header of the target block and extract the third total digest from the first block header. The third total digest is a summary of the state of each transaction object in the target block before the transaction is executed.

[0211] Step 1120: Obtain the second block header of the previous block of the target block, and extract the fourth total digest from the second block header. The fourth total digest is a total digest of the state of each transaction object after the execution of the transaction in the previous block.

[0212] Step 1130: If the third general digest is consistent with the fourth general digest, determine that the first block header is valid, and extract the first general digest from the first block header.

[0213] Steps 1110 to 1130 are described in detail below:

[0214] In step 1110, the first block header of the target block is obtained, and the third total digest is extracted from the first block header. The third total digest is a summary of the state of each transaction object in the target block before the transaction is executed.

[0215] According to embodiments of this disclosure, referring to Figure 12The first block header of the target block includes not only a summary of the states of all transaction objects after all transactions in the target block have been executed (the first summary), but also a summary of the states of all transaction objects before the execution of the transactions in the target block (the third summary). For example, suppose the transaction objects include resource pool A and resource pool B, and the target block contains only one transaction: "Transfer 30 resources from resource pool A to resource pool B". Before the transaction is executed, resource pool A has 100 resources, and resource pool B has 50 resources. After the transaction in the target block is executed, resource pool A has 70 resources, and resource pool B has 80 resources. In this case, firstly, the number of resources in resource pool A (100) before the transaction in the target block is hashed to obtain hash value 1, and the number of resources in resource pool B (50) before the transaction is hashed to obtain hash value 2. Then, hash value 1 and hash value 2 are concatenated and hashed to obtain hash value 12, which is the third summary. Furthermore, a hash calculation is performed on the number of resources 70 in resource pool A after the transaction is executed, yielding a hash value of 3. A hash calculation is performed on the number of resources 80 in resource pool B after the transaction is executed, yielding a hash value of 4. Then, hash values ​​3 and 4 are concatenated and hashed together to obtain a hash value of 34. This hash value of 34 is the first master digest.

[0216] In step 1120, the second block header of the previous block of the target block is obtained, and the fourth total digest is extracted from the second block header. The fourth total digest is a total digest of the state of each transaction object after the execution of the transaction in the previous block.

[0217] According to embodiments of this disclosure, the preceding block of the target block refers to the last block recorded in the blockchain before the target block is recorded therein. For example, see... Figure 7 Assuming the blockchain includes blocks 1, 2, 3, and 4, and the target block has not yet been recorded on the blockchain, we can deduce that the block preceding the target block is block 4.

[0218] It is understandable that the second block header refers to the block header of the block preceding the target block. (See reference...) Figure 12 The second block header of the block preceding the target block contains a summary of the states of all transaction objects after the execution of the transactions in the previous block, i.e., the fourth summary. Moreover, the meaning of the fourth summary relative to the block preceding the target block is equivalent to the meaning of the first summary relative to the target block; both are summaries of the states of all transaction objects after the execution of the transactions in that block.

[0219] For example, assume the preceding block to the target block is block A. The transaction objects include resource pool C and resource pool D. Block A contains only one transaction: resource pool C transfers 20 resources to resource pool D. Before the transaction, resource pool C has 80 resources, and resource pool D has 70 resources. After the transaction, resource pool C has 60 resources, and resource pool D has 90 resources. The target block also contains only one transaction: resource pool D transfers 10 resources to resource pool C. Before the target block, resource pool C has 60 resources, and resource pool D has 90 resources. After the target block, resource pool C has 70 resources, and resource pool D has 80 resources.

[0220] In this scenario, hashing the 60 resources in resource pool C after the transaction execution of block A yields hash value 1, and hashing the 90 resources in resource pool D after the transaction execution of block A yields hash value 2. Concatenating hash values ​​1 and 2 and performing a hash calculation yields hash value 12, which is the fourth total digest. Similarly, hashing the 60 resources in resource pool C before the transaction execution of the target block yields hash value 3, and hashing the 90 resources in resource pool D before the transaction execution of the target block yields hash value 4. Performing a hash calculation on hash values ​​3 and 4 yields hash value 34, which is the third total digest. Furthermore, hashing the 70 resources in resource pool C after the transaction execution of the target block yields hash value 5, and hashing the 80 resources in resource pool D after the transaction execution of the target block yields hash value 6. Then, hash value 5 and hash value 6 are concatenated and hashed together to obtain hash value 56, which is the first total digest.

[0221] In step 1130, if the third total digest is consistent with the fourth total digest, the first block header is determined to be valid, and the first total digest is extracted from the first block header.

[0222] According to embodiments of this disclosure, referring to Figure 12If the third and fourth total digests are consistent, it indicates that the total digest of the states of each transaction object before the execution of the transaction in the target block is consistent with the total digest of the states of each transaction object after the execution of the transaction in the previous block. In other words, the states of each transaction object before the execution of the transaction in the target block are the same as the states of each transaction object after the execution of the transaction in the previous block. Based on this, the trusted execution environment of the target blockchain node can determine that the first block header of the target block is valid. At this time, the trusted execution environment can be used to extract the first total digest from the first block header. Furthermore, the embodiments of this disclosure utilize a trusted execution environment to verify the link between the target block and the block preceding the target block, ensuring that no external interference is received during the link verification process, thus improving the reliability of the verification.

[0223] According to embodiments of this disclosure, it is assumed that the second block header of the block preceding the target block is Header. N-1 The first block header of the target block is Header N The following function can be used to verify whether there is a link between the target block and the block preceding the target block:

[0224] Res=Enclave.VERIFY_HEADER(Header N Header N-1 );

[0225] Here, Res represents the result of judging whether the first block header is valid. If there is a link between the target block and the block preceding the target block, the first block header is valid and Res is true. If there is no link between the target block and the block preceding the target block, the first block header is invalid and Res is false. Enclave.VERIFY_HEADER represents the function that verifies whether there is a link between the target block and the block preceding the target block in a trusted execution environment.

[0226] The specific method for determining the validity of the first block header if the third general digest matches the fourth general digest will be described in detail below.

[0227] The embodiments of steps 1110 to 1130 above, by using a trusted execution environment to compare the third total digest in the first block header of the target block with the fourth total digest in the second block header of the previous block of the target block, ensure that the process of verifying the link between the target block and the previous block of the target block is not subject to external interference, which not only improves the credibility of the verification, but also improves the reliability of the first total digest extracted from the first block header.

[0228] In one embodiment, reference is made to Figure 13 Step 1130 includes:

[0229] Step 1310: In response to the consistency between the third and fourth total digests, obtain the consensus protocol version number from the first block header;

[0230] Step 1320: If the obtained consensus protocol version number belongs to the predetermined version number set, determine that the first block header is valid.

[0231] Steps 1310 and 1320 are described in detail below:

[0232] In step 1310, in response to the consistency between the third and fourth total digests, the consensus protocol version number is obtained from the first block header.

[0233] According to embodiments of this disclosure, a consensus protocol is a protocol used to ensure that all blockchain nodes in a blockchain network reach a consensus on the state of transaction objects to be recorded in a target block of the blockchain. Currently, there are various types of consensus protocols, including Proof-of-Work, Proof-of-Stake, and Delegated Proof-of-Stake. To distinguish between different types of consensus protocols, the type of consensus protocol can be identified by its version number. Proof-of-Work verifies the amount of work done by each blockchain in the blockchain network using a cryptographic hash function, thereby ensuring that nodes in the blockchain network must expend certain computational resources to generate a new block. Proof-of-Stake determines the probability of a blockchain node generating a new block based on the amount of resources it holds. Delegated Proof-of-Stake selects block producers through voting, reducing unnecessary consumption of computational resources.

[0234] Furthermore, the consensus protocol version number is typically recorded in the first block header of the target block, such as... Figure 14 As shown. If the third and fourth total digests are consistent, it means that the states of each transaction object before the execution of the transaction in the target block are the same as the states of each transaction object after the execution of the transaction in the previous block. In this case, in response to the consistency of the third and fourth total digests, the consensus protocol version number is obtained from the first block header of the target block.

[0235] In step 1320, if the obtained consensus protocol version number belongs to the predetermined version number set, the first block header is determined to be valid.

[0236] According to embodiments of this disclosure, the choice of consensus protocol has a significant impact on the performance, security, and efficiency of a blockchain network. Different consensus protocols have different advantages and disadvantages and are suitable for different application scenarios (e.g., while Proof-of-Work offers high security, it consumes a large amount of computational energy; while Proof-of-Stake and Delegated Proof-of-Stake are more energy-efficient, they may face centralization risks). Therefore, to adapt to different application scenarios, different types of blockchain networks can specify the use of different types of consensus protocols, and the predetermined version number set refers to the set of consensus protocol version numbers specified by the blockchain network. To maintain the security of the blockchain, the consensus protocol of blocks in the blockchain network must conform to the predetermined version number set of the blockchain network.

[0237] Understandably, if the obtained consensus protocol version number belongs to a predetermined set of version numbers, then the target block is determined to comply with the requirements of the blockchain network, and the first block header is determined to be valid. If the obtained consensus protocol version number does not belong to the predetermined set of version numbers, then the target block is determined to not comply with the requirements of the blockchain network, and the first block header is determined to be invalid. For example, suppose the predetermined set of version numbers includes Proof-of-Work, and the consensus protocol version number obtained from the first block header of the target block is also Proof-of-Work. In this case, the first block header can be determined to be valid.

[0238] The embodiments of steps 1310 to 1320 described above can determine the validity of the first block header of the target block by obtaining the consensus protocol version number from the first block header of the target block and comparing the obtained consensus protocol version number with the predetermined version number set of the blockchain network. This method ensures that the consensus protocol version numbers of blocks in the blockchain network all conform to the predetermined version number set, thus maintaining the security of the blockchain.

[0239] In one embodiment, reference is made to Figure 15 Step 310 includes:

[0240] Step 1510: Obtain the first block identifier of the target block;

[0241] Step 1520: Integrate the first general summary and the first block identifier to obtain the first integrated body;

[0242] Step 1530: Encrypt the first integrated entity to obtain the first ciphertext;

[0243] Step 1540: Store the first ciphertext and the first block identifier in the ciphertext storage space.

[0244] Steps 1510 to 1540 are described in detail below:

[0245] In step 1510, the first block identifier of the target block is obtained.

[0246] According to embodiments of this disclosure, the first block identifier refers to a sequence number used to identify the target block, and the first block identifier can indicate the position and order of the target block in the blockchain. In the blockchain, each block has a unique sequence number for identification.

[0247] Understandably, the first block identifier is recorded in the first block header of the target block. After the blockchain node's blockchain ledger program extracts the first block header of the target block, the trusted execution environment extracts the first block identifier from the first block header, such as... Figure 16 As shown.

[0248] In step 1520, the first general summary and the first block identifier are integrated to obtain the first integrated body.

[0249] According to embodiments of this disclosure, the first integrated body refers to a group of elements concatenated from a first general summary and a first block identifier. Through the first integrated body, the block corresponding to the first block identifier can be quickly located, and the state of each transaction object in that block can be verified based on the first general summary. For example, assuming there is a target block with a first general summary of "Stateroot1" and a first block identifier of "X", after integrating the first general summary and the first block identifier, the first integrated body can be obtained as (Stateroot1, X).

[0250] In step 1530, the first integrated body is encrypted to obtain the first ciphertext.

[0251] According to embodiments of this disclosure, encrypting the first integrated entity refers to using an encryption algorithm to calculate the plaintext first integrated entity to obtain unreadable data, i.e., the first ciphertext, thus protecting the first integrated entity from external reading and tampering. Furthermore, encryption algorithms can be broadly classified into symmetric and asymmetric encryption. Symmetric encryption algorithms include Data Encryption Standard (DES), Triple Data Encryption (TDE), and Advanced Encryption Standard (AES), while asymmetric encryption includes public-key encryption algorithms and digital signature algorithms. Each of these encryption methods has its advantages and disadvantages, and is suitable for different scenarios and needs. Symmetric encryption algorithms are generally faster, but require secure key transmission, while asymmetric encryption algorithms do not require key transmission but have higher computational complexity. In actual operation, the encryption algorithm can be determined based on the specific blockchain application scenario to encrypt the first integrated entity and obtain the first ciphertext.

[0252] In step 1540, the first ciphertext and the first block identifier are stored in the ciphertext storage space.

[0253] Understandably, when a blockchain node receives a request from a target terminal to retrieve the state of a target transaction object after one or more transactions have been executed, it needs to use a trusted execution environment to retrieve the first ciphertext corresponding to the target block from the ciphertext storage space. However, since the first ciphertext is unreadable data, if the ciphertext storage space only stores the first ciphertext, it is unclear which first ciphertext corresponds to the target block when retrieving the first ciphertext corresponding to the target block in the trusted execution environment. Therefore, embodiments of this disclosure can store the first ciphertext corresponding to the first block identifier in the ciphertext storage space, such as... Figure 17 As shown. Based on Figure 17 It can be seen that after storing the first ciphertext and the first block identifier in the ciphertext storage space, the ciphertext "0xFFEA" is stored in the ciphertext storage space corresponding to block identifier "1", meaning that the ciphertext corresponding to block identifier 1 is 0xFFEA. The ciphertext "0xFFEB" is stored in the ciphertext corresponding to block identifier "2", meaning that the ciphertext corresponding to block identifier 2 is 0xFFEB. The ciphertext "0xFFEC" is stored in the ciphertext corresponding to block identifier "3", meaning that the ciphertext corresponding to block identifier 3 is 0xFFEC. The first ciphertext is stored in the ciphertext corresponding to the first block identifier, meaning that the ciphertext corresponding to the block with the first block identifier is the first ciphertext.

[0254] It is understandable that the first ciphertext and the first block identifier stored in the ciphertext storage space can be represented by Row, and Row = <EnclaveText N ,N>;where,EnclaveText N N represents the first ciphertext; N represents the first block identifier. Because the first block identifier is used to identify the sequence number of the target block, the first ciphertext corresponding to the target block can be quickly determined in the ciphertext storage space based on the first block identifier, thus improving the efficiency of the trusted execution environment in obtaining the first ciphertext.

[0255] The embodiments of steps 1510 to 1540 described above encrypt the first integrated entity formed by integrating the first general digest and the first block identifier to obtain the first ciphertext, thereby protecting the first general digest and the first block identifier from being read and tampered with externally. Furthermore, the embodiments of this disclosure store the first ciphertext and the first block identifier correspondingly in a ciphertext storage space. Based on the first block identifier, the first ciphertext corresponding to the target block can be quickly determined in the ciphertext storage space, improving the efficiency of the trusted execution environment in obtaining the first ciphertext.

[0256] Detailed description of step 320

[0257] Step 320: Record the target block on the blockchain.

[0258] In one embodiment, reference is made to Figure 18 After step 320, the following also includes:

[0259] Step 1810: Receive a composite acquisition request from the target terminal for the composite state of the target block, wherein the composite state is associated with the states of multiple target transaction objects;

[0260] Step 1820: Using a trusted execution environment, retrieve the first ciphertext from the ciphertext storage space; decrypt the first ciphertext to obtain the recovered first total digest;

[0261] Step 1830: Obtain the states of multiple target transaction objects and the sixth total digest from the blockchain ledger program. In response to the consistency between the first and sixth total digests, generate a composite state using the obtained states of multiple target transaction objects and return it to the target terminal. The sixth total digest refers to the total digest of the states of each transaction object when the target blockchain node receives the composite acquisition request.

[0262] Steps 1810 to 1830 are described in detail below:

[0263] In step 1810, a composite acquisition request for the composite state of the target block is received from the target terminal, wherein the composite state is associated with the states of multiple target transaction objects.

[0264] According to embodiments of this disclosure, a composite acquisition request is issued by a target terminal to request a target blockchain node to obtain a composite state of multiple target transaction object states. The composite state is associated with the states of multiple target transaction objects and can be the average of the states of multiple target transaction objects, the sum of the states of multiple target transaction objects, the difference between two states of target transaction objects, etc. For example, suppose the latest target block added to the current blockchain is target block 2, which records the number of resources in resource pool A, resource pool B, and resource pool C. The number of resources in resource pool A is 70, the number of resources in resource pool B is 80, and the number of resources in resource pool C is 90. The target terminal's composite acquisition request for target block 2 requests the average of the number of resources in resource pool A, resource pool B, and resource pool C. At this time, the states of multiple target transaction objects are the number of resources in resource pool A, the number of resources in resource pool B, and the number of resources in resource pool C, respectively, and the composite state is the average of the number of resources in resource pool A minus the number of resources in resource pool C.

[0265] According to embodiments of this disclosure, a composite acquisition request includes a composite state function, which indicates the relationship between the composite state and the states of multiple target transaction objects.

[0266] It is understandable that the target terminal's composite acquisition request for the target block can be represented as RPC_TX =<EVM_MSG,BlockNumber> Where RPC_TX represents a composite retrieval request; EVM_MSG represents a composite state function; and BlockNumber represents the first block identifier corresponding to the target block.

[0267] Furthermore, the composite state function can be defined by the target terminal. For example, suppose the latest target block added to the current blockchain is target block 1, and target block 1 records the number of resources in resource pool A, resource pool B, and resource pool C. If the target terminal's composite acquisition request for target block 1 requests the average of the number of resources in resource pool A and resource pool C, the composite state function is a function that calculates the average of the number of resources in resource pool A, resource pool B, and resource pool C. If the target terminal's composite acquisition request for target block 1 requests the difference between the number of resources in resource pool A and resource pool B, the composite state function is a function that calculates the difference between the number of resources in resource pool A and resource pool B. If the target terminal's composite acquisition request for target block 1 requests the sum of the number of resources in resource pool A, resource pool B, and resource pool C, the composite state function is a function that calculates the sum of the number of resources in resource pool A, resource pool B, and resource pool C.

[0268] In step 1820, a trusted execution environment is used to obtain the first ciphertext from the ciphertext storage space; based on the first ciphertext, decryption processing is performed to obtain the recovered first total digest.

[0269] According to embodiments of this disclosure, since the first ciphertext in the ciphertext storage space is stored corresponding to the first block identifier, when retrieving the first ciphertext from the ciphertext storage space using a trusted execution environment, the first ciphertext corresponding to the first block identifier can be obtained based on the first block identifier carried in the composite state retrieval request. For example, assuming the first block identifier is X, the process of retrieving the first ciphertext from the ciphertext storage space can be represented as: Row = QUERY(“SELECT EnclaveText WHERE BlockNumber = X”); where Row represents an element group composed of the first ciphertext and the first block identifier, and the obtained Row here is an element group composed of the first block identifier with the value X and the corresponding first ciphertext; QUERY represents a function that performs a query operation in the ciphertext storage space; “SELECT EnclaveText WHERE BlockNumber = X” represents the first ciphertext corresponding to the first block identifier with the value X in the ciphertext storage space. After obtaining the element group Row composed of the first ciphertext and the first block identifier, the first ciphertext can be directly extracted from the element group Row.

[0270] It is understandable that the specific implementation process of "decrypting based on the first ciphertext to obtain the recovered first total digest" in step 1820 is similar to the specific implementation process of "decrypting based on the first ciphertext to obtain the recovered first total digest" in step 330, and will not be described in detail here.

[0271] In step 1830, multiple target transaction object states and a sixth total digest are obtained from the blockchain ledger program. In response to the consistency between the first and sixth total digests, a composite state is generated using the obtained multiple target transaction object states and returned to the target terminal. The sixth total digest refers to the total digest of the states of each transaction object when the target blockchain node receives the composite acquisition request.

[0272] According to embodiments of this disclosure, the sixth total digest refers to a total digest of the states of each transaction object when the composite retrieval request is received. Specifically, the sixth total digest generally refers to the total hash value calculated based on the hash values ​​of the states of each transaction object when the composite retrieval request is received, after hashing the states of each transaction object.

[0273] It is understandable that in step 330, the retrieval request sent by the target terminal for the target block requests the state of a single target transaction object within the target block. In this case, after the trusted execution environment obtains the target transaction object state and the second total digest from the blockchain ledger, if the second total digest matches the first total digest, it can directly return the target transaction object state to the target terminal. Unlike step 330, in step 1810, the composite retrieval request from the target terminal for the composite state of the target block involves the composite state being associated with multiple target transaction object states. In this case, after the trusted execution environment obtains multiple target transaction object states from the blockchain ledger, if the sixth total digest matches the first total digest, it does not directly return these multiple target transaction object states to the target terminal. Instead, it needs to generate a composite state using the obtained multiple target transaction object states and then return the composite state to the target terminal.

[0274] For example, refer to Figure 19 Suppose the target blockchain node receives a composite request from the target terminal for the composite state of the target block, which is associated with target transaction object state 1 and target transaction object state 2. Following this, the target blockchain node's trusted execution environment retrieves the first ciphertext corresponding to the target block from the ciphertext storage space and performs decryption processing based on the first ciphertext to recover the first total digest in the first block header of the target block. Then, the trusted execution environment retrieves target transaction object state 1, target transaction object state 2, and a sixth total digest from the blockchain ledger program. If the sixth total digest matches the first total digest, the trusted execution environment will use the retrieved target transaction object state 1 and target transaction object state 2 to generate a composite state. Finally, the trusted execution environment returns the composite state generated from target transaction object state 1 and target transaction object state 2 to the target terminal.

[0275] It is understandable that generating a composite state using the acquired states of multiple target transaction objects includes: substituting the acquired states of multiple target transaction objects into a composite state function to obtain a composite state.

[0276] For example, suppose there are three transaction objects, namely resource pools AC. After the transaction in the target block is completed, the number of resources in resource pool A is 40, the number of resources in resource pool B is 50, and the number of resources in resource pool C is 60. If the target terminal's composite acquisition request for the target block requests the average number of resources in resource pool AC after the transaction in the target block is completed, the composite state function is: Composite State = (Number of resources in resource pool A + Number of resources in resource pool B + Number of resources in resource pool C + ... + Number of resources in resource pool N) / N; Based on this, substituting the number of resources in resource pool A, resource pool B, resource pool C, ..., resource pool N into the composite state function, we obtain a composite state of 50.

[0277] In the embodiments of steps 1810 to 1830 above, after the target blockchain is uploaded, if a composite retrieval request for the composite state of the target block is received, the first total digest is recovered from the first ciphertext stored in the ciphertext storage space using a trusted execution environment. Simultaneously, multiple target transaction object states and a sixth total digest are requested from the blockchain ledger program. The first total digest refers to the total digest of the states of each transaction object after the transaction execution of the target block, and the sixth total digest refers to the total digest of the states of each transaction object when the composite retrieval request is received. If the two are consistent, it indicates that the query result is accurate and has not been tampered with. The obtained multiple target transaction object states can be used to generate a composite state, which is then returned to the target terminal. This method not only quickly determines the states of multiple target transaction objects and calculates the composite state when the composite state is associated with multiple target transaction object states, improving query efficiency, but also ensures the security of transaction object state queries.

[0278] Detailed description of step 330

[0279] Step 330: In response to the target terminal's request to obtain the state of the target transaction object after one or more transactions have been executed, the trusted execution environment is used to obtain the first ciphertext from the ciphertext storage space, and the first ciphertext is decrypted to obtain the recovered first total digest.

[0280] In one embodiment, reference is made to Figure 20 Step 330 includes:

[0281] Step 2010: Obtain the first block identifier from the retrieval request;

[0282] Step 2020: Obtain the second ciphertext stored in the ciphertext storage space that corresponds to the first block identifier;

[0283] Step 2030: Decrypt the second ciphertext to obtain the second integrated entity;

[0284] Step 2040: Obtain the fifth overall digest and the third block identifier from the second integration;

[0285] Step 2050: In response to the fact that the third block identifier is consistent with the first block identifier, the fifth total digest is determined as the recovered first total digest.

[0286] Steps 2010 to 2050 are described in detail below:

[0287] In step 2010, the first block identifier is obtained from the acquisition request.

[0288] According to embodiments of this disclosure, the first ciphertext in the ciphertext storage space is stored corresponding to the first block identifier. To facilitate the rapid retrieval of the first ciphertext corresponding to the target block from the ciphertext storage space when a request to obtain the state of a target transaction object after one or more transactions have been executed is received, the retrieval request typically carries the first block identifier, such as... Figure 21 As shown.

[0289] In step 2020, the second ciphertext corresponding to the first block identifier is retrieved from the ciphertext storage space.

[0290] According to embodiments of this disclosure, referring to Figure 22 Upon receiving a request from the target terminal to retrieve the state of a target transaction object after one or more transactions have been executed, the Trusted Execution Environment (TEE) extracts a first block identifier from the request and retrieves the second ciphertext corresponding to the first block identifier from an external ciphertext storage space. The second ciphertext is the ciphertext stored in the ciphertext storage space corresponding to the first block identifier. Since the ciphertext storage space is external to the TEE and therefore untrusted, both the ciphertext and the block identifier stored in the ciphertext storage space are susceptible to tampering by the cloud service provider (whether the ciphertext stored in the ciphertext storage space or the block identifier is tampered with, the corresponding ciphertext retrieved based on the block identifier will be incorrect). To distinguish it from the first ciphertext corresponding to the first block identifier stored in the ciphertext storage space by the TEE, the ciphertext stored in the ciphertext storage space corresponding to the first block identifier is defined as the second ciphertext. In other words, the first ciphertext corresponding to the first block identifier initially stored in the ciphertext storage space by the TEE is a trusted ciphertext. The second ciphertext stored in the ciphertext storage space, corresponding to the first block identifier, is the first ciphertext that may be tampered with externally and is therefore unreliable.

[0291] For example, refer to Figure 21Assuming the first block identifier obtained by the blockchain node from the acquisition request is 3, the trusted execution environment queries the ciphertext and block identifier stored in the ciphertext storage space and obtains the second ciphertext stored corresponding to the first block identifier as 0xFEFEC.

[0292] In step 2030, the second ciphertext is decrypted to obtain the second integrated entity.

[0293] According to embodiments of this disclosure, the second integrated body refers to the group of elements obtained after decrypting the second ciphertext. When neither the first block identifier nor the second ciphertext has been externally tampered with, the group of elements contained in the second integrated body is the same as the first block identifier and the first ciphertext. When either the first block identifier or the second ciphertext has been externally tampered with, the second integrated body is different from the first block identifier and the first ciphertext.

[0294] It is understandable that the decryption method used for decryption based on the second ciphertext corresponds to the encryption method used for encryption based on the first total digest in step 310. For example, if the encryption algorithm used for encryption based on the first total digest in step 310 is a symmetric encryption algorithm, then the key used for decryption based on the second ciphertext is the same as the key used for encryption based on the first total digest. If the encryption algorithm used for encryption based on the first total digest in step 310 is an asymmetric encryption algorithm, then the key used for decryption based on the second ciphertext is different from the key used for encryption based on the first total digest. That is, two keys are used for encryption and decryption.

[0295] In step 2040, the fifth overall summary and the third block identifier are obtained from the second integration.

[0296] According to embodiments of this disclosure, both the fifth master digest and the third block identifier are elements included in the second integrator. Here, to distinguish them from the first master digest and first block identifier contained in the first integrator, the master digest in the second integrator is defined as the fifth master digest, and the block identifier in the second integrator is defined as the third block identifier. It can also be understood that the first block identifier and first master digest initially obtained by the trusted execution environment from the target block are trustworthy. The second integrator is obtained by decrypting a second ciphertext that is not trustworthy; therefore, the fifth master digest and third block identifier in the second integrator are also not trustworthy.

[0297] In step 2050, in response to the third block identifier being consistent with the first block identifier, the fifth total digest is determined as the recovered first total digest.

[0298] According to embodiments of this disclosure, the reason for verifying whether the third block identifier is consistent with the first block identifier is to determine the correctness of the fifth total digest. If the first block identifier or the second ciphertext in the ciphertext storage space is tampered with by the cloud service provider, then the second concatenation obtained after decrypting the second ciphertext corresponding to the first block identifier will be incorrect, and the third block identifier and the fifth total digest contained in the second concatenation will also naturally be incorrect. In this case, if the incorrect fifth total digest is determined as the recovered first total digest, it will lead to querying the incorrect target transaction object state. Based on this, after obtaining the third block identifier and the first block identifier from the second concatenation, it is necessary to compare whether the third block identifier is consistent with the first block identifier. If the first block identifier and the second ciphertext in the ciphertext storage space have not been tampered with by the cloud service provider, then the second concatenation obtained after decrypting the second ciphertext corresponding to the first block identifier will be consistent with the first concatenation. The third block identifier contained in the second concatenation will also be consistent with the first block identifier, and the fifth total digest contained in the second concatenation will also be consistent with the first total digest. Therefore, if the third block identifier is the same as the first block identifier, the fifth total digest can be determined as the recovered first total digest in response to the fact that the third block identifier is the same as the first block identifier.

[0299] For example, suppose the trusted execution environment obtains the first block identifier of the target block as 2, and the first total digest as stateroot2. After integrating the first total digest and the first block identifier, the first integrated body is (stateroot2, 2). After encrypting the first integrated body, the trusted execution environment obtains the first ciphertext as "0xFEFEB". After obtaining the first ciphertext, it stores the first ciphertext and the first block identifier in the ciphertext storage space, displayed as (0xFEFEB, 2). Suppose that after storing the first ciphertext and the first block identifier in the ciphertext storage space, the cloud service provider modifies the first ciphertext to "0xFEFEA". Then, the subsequent target blockchain node obtains the second ciphertext stored in the ciphertext storage space, corresponding to the first block identifier with the value "2", as "0xFEFEA". Suppose that after decrypting the second ciphertext, the second integrated body is obtained as (stateroot1, 1), the obtained fifth total digest is stateroot1, and the third block identifier is 1. At this point, the identifier of the third block is inconsistent with the identifier of the first block, which can quickly determine that the second ciphertext has been tampered with by the cloud service provider.

[0300] In the embodiments of steps 2010 to 2050 above, if the first block identifier or the second ciphertext in the ciphertext storage space is tampered with by the cloud service provider, then the second concatenation obtained after decrypting the second ciphertext corresponding to the first block identifier will be incorrect, and the third block identifier and the fifth total digest contained in the second concatenation will also naturally be incorrect. The embodiments of this disclosure, by comparing whether the third block identifier and the first block identifier are consistent, can quickly determine whether the second ciphertext has been tampered with by the cloud service provider, avoiding the return of an incorrect target transaction object status to the target terminal.

[0301] Reference Figure 23 In one embodiment, step 1520 includes:

[0302] Step 2310: Interleave the first general summary and the first block identifier according to the target interleaving rules to obtain the first integrated body;

[0303] Step 2040 includes:

[0304] Step 2320: Deinterleave the second integrator according to the target interleaving rules to obtain the fifth overall summary and the third block identifier.

[0305] Steps 2310 and 2320 are described in detail below:

[0306] In step 2310, the first general summary and the first block identifier are interleaved according to the target interleaving rules to obtain the first integrated body.

[0307] According to embodiments of this disclosure, both the first total digest and the first block identifier are represented as a series of data streams. Interleaving refers to the method of interleaving the data stream corresponding to the first total digest and the data stream corresponding to the first block identifier together. Because the first integrated body obtained after interleaving the first total digest and the first block identifier is not readable, interleaving the first total digest and the first block identifier can increase the difficulty for external parties to read them, thereby improving the reliability and security of the blockchain nodes. The interleaving rule refers to the method of interleaving the data stream corresponding to the first total digest and the data stream corresponding to the first block identifier together. For blockchains belonging to different application scenarios, different interleaving rules can be selected based on the security level required by that application scenario, and the target interleaving rule refers to the interleaving rule selected by the blockchain.

[0308] For example, suppose the data stream of the first total digest can be represented as "AAABBB", and the data stream of the first block identifier can be represented as "111222". The target interleaving rule is to split the data stream of the first total digest and the data stream of the first block identifier into two parts respectively, and then interleave the two parts corresponding to the first total digest and the two parts corresponding to the first block identifier respectively. Based on this, after interleaving the first total digest and the first block identifier according to the target interleaving rule, the first integrated body is "AAA111BBB222". Here, "AAA" and "BBB" are the two parts of the data stream of the first total digest, and "111" and "222" are the two parts of the data stream of the first block identifier.

[0309] The specific method for "interweaving the first general summary and the first block identifier according to the target interleaving rules to obtain the first integrated body" will be described in detail below.

[0310] In step 2320, the second integrator is de-interleaved according to the target interleaving rules to obtain the fifth total digest and the third block identifier.

[0311] According to embodiments of this disclosure, deinterleaving refers to separating the data streams of interleaved original data to obtain readable original data. Furthermore, the deinterleaving method corresponds to the interleaving method. If the interleaving rules used when interleaving the first general digest and the first block identifier are inconsistent with the interleaving rules used when deinterleaving the second integrated body, the second integrated body cannot be successfully deinterleaved.

[0312] For example, suppose the data stream of the first total digest can be represented as "CCCDDDEEE", and the data stream of the first block identifier can be represented as "334455". The target interleaving rule is to split the data stream of the first total digest and the data stream of the first block identifier into three parts respectively, and then interleave the three parts corresponding to the first total digest and the three parts corresponding to the first block identifier respectively. Based on this, after interleaving the first total digest and the first block identifier according to the target interleaving rule, the first integrated body is "CCC33DDD44EEE55". Suppose that the second integrated body obtained after decrypting the second ciphertext is "CCC33DDD44EEE55", and after deinterleaving the second integrated body according to the target interleaving rule, the data stream of the fifth digest is "CCCDDDEEE", and the data stream of the third block identifier is "334455".

[0313] The specific method for "de-interleaving the second integrator according to the target interleaving rules to obtain the fifth general summary and the third block identifier" will be described in detail below.

[0314] The embodiments of steps 2310 to 2320 described above, by interleaving the first total digest and the first block identifier to obtain the first integrated body, can increase the difficulty for external reading of the first total digest and the first block identifier, thereby improving the reliability and security of the blockchain node. Furthermore, the embodiments of this disclosure can deinterleave the second integrated body according to the target interleaving rule when reading is required, to obtain the fifth total digest and the third block identifier, thus improving the reliability and security of the blockchain node without affecting reading efficiency.

[0315] In one embodiment, reference is made to Figure 24 Step 2310 includes:

[0316] Step 2410: Extract the target block type from the first block header;

[0317] Step 2420: Determine the target interleaving rules based on the target block type;

[0318] Step 2430: Interweave the first general summary and the first block identifier according to the determined target interweaving rules to obtain the first integrated body.

[0319] Steps 2410 to 2430 are described in detail below:

[0320] In step 2410, the target block type of the target block is extracted from the first block header.

[0321] According to embodiments of this disclosure, the target block type refers to the type of transactions involved in the target block. For example, when the transactions contained in the target block are all traffic flow information at various traffic intersections, the target block type is traffic data. When the transactions contained in the target block are all resource interactions between resource pools, the target block type is resource interaction.

[0322] It is understandable that the first block header of the target block contains the target block type, and the trusted execution environment can obtain the target block type of the target block by extracting the first block header of the target block.

[0323] In step 2420, the target interleaving rule is determined based on the target block type.

[0324] According to embodiments of this disclosure, different target block types require different security levels. Generally, resource interaction target blocks require higher security levels, while public transaction target blocks require lower security levels. If the target block type is resource interaction, more complex target interleaving rules can be set for it. If the target block type is public transaction, simpler target interleaving rules can be set for it.

[0325] In step 2430, the first general summary and the first block identifier are interleaved according to the determined target interleaving rules to obtain the first integrated body.

[0326] For example, refer to Figure 25A Suppose the target block type extracted from the first block header is a resource interaction type. In this case, the target block type requires a high security level, and a relatively complex interleaving rule can be determined as the target interleaving rule. This target interleaving rule can be: splitting the first total digest and the first block identifier into multiple fields, each assigned its own sequence number; then concatenating fields with the same sequence number in the first total digest and the first block identifier to obtain a sub-concatenation result with that sequence number; and then concatenating these sub-concatenation results according to their sequence numbers to obtain the interleaved result. Figure 25A Specifically, the process is as follows: After splitting the first overall summary, fields A, B, C, and D are obtained. After splitting the data stream of the first block identifier, fields E, F, G, and H are obtained. Fields A and E with the first sequence number are concatenated to obtain sub-concatenation result AE. Fields B and F with the second sequence number are concatenated to obtain sub-concatenation result BF. Fields C and G with the third sequence number are concatenated to obtain sub-concatenation result CG. Fields D and H with the fourth sequence number are concatenated to obtain sub-concatenation result DH. The interleaved result obtained by concatenating each sub-concatenation result according to its sequence number is AEBFCGDH.

[0327] Reference Figure 25B Suppose the target block type extracted from the first block header is a public transaction type. In this case, the target block type requires a lower security level, and a relatively simple interleaving rule can be determined as the target interleaving rule. This target interleaving rule could be: split the data stream of the first general digest into two fields, and insert the field corresponding to the first block identifier between the two fields corresponding to the first general digest. Figure 25B Specifically, the first total digest is split to obtain field A and field B, and the field corresponding to the first block identifier is field D. The first total digest and the first block identifier are then interleaved according to a defined target interleaving rule, resulting in an interleaved ADB.

[0328] The embodiments of steps 2410 to 2430 described above can determine the target interleaving rules based on the target block type. This allows for the determination of more complex target interleaving rules for target block types with higher security levels, and simpler target interleaving rules for target block types with lower security levels. Through this method, different target interleaving rules can be determined for blocks in different application scenarios, improving both the security of the first general digest transmission and its versatility across various application scenarios.

[0329] In one embodiment, reference is made to Figure 26 Step 2320 includes:

[0330] Step 2610: Obtain the target block type from the retrieval request;

[0331] Step 2620: Determine the target interleaving rules based on the target block type;

[0332] Step 2630: Deinterleave the second integrator according to the determined target interleaving rules to obtain the fifth general summary and the third block identifier.

[0333] Steps 2610 to 2630 are described in detail below:

[0334] In step 2610, the target block type of the target block is obtained from the acquisition request.

[0335] According to embodiments of this disclosure, the retrieval request contains the target block type of the target block, and the trusted execution environment can obtain the target block type of the target block by parsing and extracting the retrieval request.

[0336] In step 2620, the target interleaving rule is determined based on the target block type.

[0337] It is understood that the embodiment of step 2620 above has already explained the method of "determining target interleaving rules based on target block type", and will not be repeated here.

[0338] In step 2630, the second integrator is de-interleaved according to the determined target interleaving rules to obtain the fifth general summary and the third block identifier.

[0339] For example, refer to Figure 27AAssume the target block type obtained from the retrieval request is a resource interaction class. As mentioned above, the target interleaving rule for resource interaction classes is as follows: The first total digest and the first block identifier are split into multiple fields, each assigned its own sequence number. Then, fields with the same sequence number in the first total digest and the first block identifier are concatenated to obtain a sub-concatenation result for that sequence number. These sub-concatenation results are then concatenated according to their sequence numbers to obtain the interleaved result. Deinterleaving is performed on the second integrator AEBFCGDH in the example above. Note that during interleaving, the first integrator AEBFCGDH is obtained. Since it is impossible to determine whether the object to be deinterleaved is exactly the first integrator during deinterleaving, it is assumed that the integrator AEBFCGDH, as the object to be deinterleaved, is the second integrator. The second integrator is deinterleaved according to the reverse process of the target interleaving rule to obtain the fifth total digest and the third block identifier. If the obtained fifth total digest matches the first total digest, and the third block identifier matches the first block identifier, then the second integrator is verified to be the first integrator.

[0340] In the example above, when deinterleaving the second integrator AEBFCGDH, following the reverse process of the target interleaving rule, the second integrator AEBFCGDH is first divided into four sub-concatenation results: AE, BF, CG, and DH. Theoretically, AE is the concatenation result of the first field in the fifth overall digest and the third block identifier. BF is the concatenation result of the second field in the fifth overall digest and the third block identifier. CG is the concatenation result of the third field in the fifth overall digest and the third block identifier. DH is the concatenation result of the fourth field in the fifth overall digest and the third block identifier. Therefore, the restored fifth overall digest is ABCD, and the restored third block identifier is EFGH.

[0341] Reference Figure 27B Assume the target block type obtained from the retrieval request is a public transaction class. As mentioned above, the target interleaving rule for public transaction classes is: split the data stream of the first general digest into two fields, and insert the field corresponding to the first block identifier between the two fields corresponding to the first general digest. Figure 27B In the second concatenation obtained after decrypting the second ciphertext, the fields are arranged in the following order: field A, field D, and field B. After deinterleaving the second concatenation according to the determined target interleaving rules, the fifth total digest is AB, and the third block identifier is D.

[0342] The embodiments of steps 2610 to 2630 above can quickly determine the corresponding target interleaving rule based on the target block type, and deinterleave the second conglomerate based on the target interleaving rule, deinterleaving the unreadable second conglomerate into a readable fifth total digest and a third block identifier, thereby improving the reliability and security of blockchain nodes without affecting reading efficiency.

[0343] In one embodiment, reference is made to Figure 28 Step 1530 includes:

[0344] Step 2810: Using the private key of the trusted execution environment, perform symmetric encryption on the first integrated body to obtain the first ciphertext;

[0345] Step 2030 includes:

[0346] Step 2820: Using the private key, perform symmetric decryption based on the second ciphertext to obtain the second integrated entity.

[0347] Steps 2810 and 2820 are described in detail below:

[0348] In step 2810, the first integrated body is symmetrically encrypted using the private key of the trusted execution environment to obtain the first ciphertext.

[0349] According to embodiments of this disclosure, the private key can be a key in a symmetric encryption algorithm, and a trusted execution environment can use the private key to encrypt and decrypt data. Because only the key holder knows the private key, it can also be used to verify the security of encrypted communication. Symmetric encryption refers to an algorithm where the same key is used for both encryption and decryption.

[0350] Understandably, the Trusted Execution Environment (TEE) holds the private key, which it can use to perform symmetric encryption on the first integrated entity, obtaining the first ciphertext. The process of the TEE performing symmetric encryption on the first integrated entity using the private key can be represented as follows:

[0351] EnclaveText N =Enclave.Encrypt(Header) N .StateRoot+":"+N);

[0352] Among them, EnclaveText N This indicates the first ciphertext; (Header) N .StateRoot+:"+N) represents the first integrator; the Enclave.Encrypt function represents symmetric encryption using the private key of a trusted environment.

[0353] The specific method for “using the private key of the trusted execution environment to perform symmetric encryption on the first integrated body to obtain the first ciphertext” will be described in detail below.

[0354] In step 2820, the private key is used to perform symmetric decryption based on the second ciphertext to obtain the second integrated entity.

[0355] According to embodiments of this disclosure, since the keys used for encryption and decryption are the same in symmetric encryption algorithms, symmetric decryption based on the second ciphertext means that the trusted execution environment uses the same private key as the key used for symmetric encryption to decrypt the second ciphertext. Further, the process of obtaining the second integrated entity through symmetric decryption based on the second ciphertext can be represented as:

[0356] Tuple2=Enclave.Decrypt(EnclaveText X ).Split(”:");

[0357] Where Tuple2 represents the second integrator; EnclaveText X This represents the second ciphertext; Enclave.Decrypt is a function that performs symmetric decryption through a trusted execution environment; Split(”:") represents parsing the symmetric decrypted second ciphertext according to the predefined separator “:”.

[0358] The specific method of "using the private key to perform symmetric decryption based on the second ciphertext to obtain the second integrated entity" will be described in detail below.

[0359] The embodiments of steps 2810 to 2820 described above can use the private key of the trusted execution environment to perform symmetric encryption on the first integrated entity during encryption to obtain the first ciphertext. Because symmetric encryption algorithms are simple to use, they greatly reduce the computational overhead of blockchain nodes. Moreover, the trusted execution environment also uses the private key to perform symmetric decryption on the second ciphertext to obtain the second integrated entity during decryption. This results in fast encryption and decryption speeds and improves the efficiency of encryption and decryption in the trusted execution environment.

[0360] In one embodiment, the trusted execution environment has multiple private keys corresponding to multiple block types, as shown below. Figure 29 Step 2810 includes:

[0361] Step 2910: Obtain the target block type of the target block from the first block header; use the private key corresponding to the target block type to perform symmetric encryption on the first integrated body to obtain the first ciphertext;

[0362] Step 2820 includes:

[0363] Step 2920: Obtain the target block type from the acquisition request; use the private key corresponding to the target block type to perform symmetric decryption based on the second ciphertext to obtain the second integrated body.

[0364] Steps 2910 and 2920 are described in detail below:

[0365] In step 2910, the target block type of the target block is obtained from the first block header; the first integrated body is symmetrically encrypted using the private key corresponding to the target block type to obtain the first ciphertext.

[0366] In this embodiment, the trusted execution environment has multiple private keys corresponding to multiple block types. Different types of private keys can be selected based on the target block type of each block, and the first consolidation is encrypted using the private key corresponding to the target block type to obtain the first ciphertext. For example... Figure 30 As shown, the target block for resource interaction corresponds to private key A, the target block for public affairs corresponds to private key B, and the target block for IoT transactions corresponds to private key C. If the target block type is resource interaction, then the first integrated body is encrypted using private key A to obtain the first ciphertext.

[0367] Similarly, in step 2920, when decrypting the second ciphertext, the private key corresponding to the target block type is used for decryption to obtain the second integrated entity. For example, if the target block type is a resource interaction type, the private key A of the resource interaction type is used to decrypt the second ciphertext to obtain the second integrated entity.

[0368] A trusted execution environment (TEA) is a relatively secure execution space. Its stored content is not easily tampered with or illegally accessed. However, due to its limited size, it often only temporarily stores parameters needed during program execution. Data that may occupy a large amount of space or will not be used for a long period is usually stored in a space outside the TEA. In this embodiment, since there may be a long interval between adding the target block to the blockchain and obtaining the transaction object state of the target block, it needs to be stored in a ciphertext storage space outside the TEA. However, the security of the ciphertext storage space is not as good as that of the TEA, and it may be illegally accessed or tampered with. In this embodiment, because different private keys are set for different target block types, even if someone illegally accesses the ciphertext storage space and obtains the first ciphertext, it is difficult to obtain the private key corresponding to the block type of the target block, and therefore difficult to decipher the final first digest, thus improving the security of the first digest storage.

[0369] In one embodiment, reference is made to Figure 31 Step 1520 includes:

[0370] Step 3110: Connect the first general summary and the first block identifier into a tuple using a predetermined delimiter to form the first integrated body;

[0371] Step 2040 includes:

[0372] Step 3120: Parse the second consolidation into tuples based on a predetermined delimiter to obtain the fifth overall summary and the third block identifier.

[0373] Steps 3110 and 3120 are described in detail below:

[0374] In step 3110, the first general summary and the first block identifier are concatenated into a tuple using a predetermined delimiter to form the first integrated body.

[0375] According to embodiments of this disclosure, a tuple refers to a new element composed of multiple data items bundled together. In embodiments of this disclosure, a tuple refers to a new element composed of a first overall digest and a first block identifier, i.e., a first integrated entity. Further, since the first overall digest and the first block identifier exist in the form of data streams, in order to separate the data stream of the first overall digest and the data stream of the first block identifier and prevent confusion between them, a simple symbol can be used to separate the first overall digest and the first block identifier. The delimiter is the symbol used to separate the first overall digest and the first block identifier. The delimiter can be a comma, a quotation mark, or a pause mark. The predetermined delimiter is the delimiter selected by the blockchain.

[0376] For example, refer to Figure 32 Assume the trusted execution environment obtains the first overall digest as HeaderN.StateRoot and the first block identifier as N. With the predetermined delimiter ":", the first overall digest and the first block identifier are concatenated into a tuple using the predetermined delimiter. The resulting first concatenated tuple is HeaderN.StateRoot + ":" + N. Here, "+" is the concatenation symbol connecting the first overall digest and the first block identifier.

[0377] In step 3120, the second consolidation is parsed based on a predetermined delimiter to obtain the fifth overall summary and the third block identifier.

[0378] According to embodiments of this disclosure, tuple parsing refers to extracting data items from a tuple. In step 3120, tuple parsing refers to extracting the fifth overall digest and the third block identifier from the second consolidation. Because multiple data items in a tuple are connected together by a predetermined delimiter, the position of the delimiter must first be determined when extracting data items from the tuple.

[0379] For example, the process of "parsing the second consolidation into tuples based on a predetermined delimiter to obtain the fifth overall digest and the third block identifier" is illustrated here with reference to the formula:

[0380] Reference Figure 33 Assuming that the second ciphertext is decrypted, the resulting second concatenation is Tuple2 = {HeaderN.StateRoot5 + "":" + N3}; where Tuple2 represents the second concatenation; HeaderN.StateRoot5 represents the fifth total digest; and N3 represents the third block identifier. Assuming the predetermined delimiter is ":", the second concatenation is parsed based on the predetermined delimiter, and after removing the connecting symbol "+", the fifth total digest HeaderN.StateRoot5 can be obtained through Tuple2[0], that is, the fifth total digest is the 0th data item in the second concatenation. The third block identifier N3 can be obtained through Tuple2[1], that is, the third block identifier is the 1st data item in the second concatenation.

[0381] The embodiments of steps 3110 to 3120 described above can concatenate the first total digest and the first block identifier into a tuple using a predetermined delimiter to form a first integrated entity, effectively preventing confusion between the first total digest and the first block identifier within the first integrated entity. Furthermore, after obtaining the second integrated entity, it can be parsed using a predetermined delimiter to obtain the fifth total digest and the third block identifier. This prevents confusion between the first total digest and the first block identifier within the first integrated entity without affecting the acquisition of the fifth total digest and the third block identifier, thus ensuring the query efficiency of the blockchain node.

[0382] Detailed description of step 340

[0383] Step 340: Obtain the state of the target transaction object and the second total digest from the blockchain ledger program, wherein the second total digest refers to the total digest of the state of each transaction object when the target blockchain node receives the acquisition request.

[0384] In one embodiment, reference is made to Figure 34 The second total summary in step 340 is generated by the blockchain ledger program in the following way:

[0385] Step 3410: Determine a summary of the state of each transaction object when the retrieval request is received;

[0386] Step 3420: Generate a second summary tree, wherein the bottommost node of the second summary tree is a summary of the state of each transaction object when the retrieval request is received. Other nodes in the first summary tree, except for the bottommost node, are generated by performing a summary operation on several adjacent nodes at the next lower level of other nodes, until the second root node at the top level is generated.

[0387] Step 3430: Determine the second general summary based on the second root node.

[0388] Steps 3410 to 3430 are described in detail below:

[0389] In step 3410, a summary of the state of each transaction object is determined when the retrieval request is received.

[0390] According to embodiments of this disclosure, since the state of the target transaction object is updated as blocks are added to the blockchain, the state of the target transaction object maintained by the blockchain ledger program of each blockchain node is also updated in real time. When the target blockchain node receives a request, it first needs to determine the summary of the current state of each transaction object. For example, refer to... Figure 35 Assume target block A contains transactions A and B. After transactions A and B are executed and the blockchain nodes successfully reach consensus on target block A, target block A is recorded on the blockchain. After transactions A and B are executed, transaction object states 5, 6, 7, and 8 can be obtained. Assume that after target block A is recorded on the blockchain, a request is received from the target terminal to retrieve the target transaction object states after one or more transactions have been executed. At this time, hash calculations are performed on transaction object states 5, 6, 7, and 8 respectively, yielding transaction object state digest values ​​5, 6, 7, and 8. Here, transaction object state digest value 5 is a digest of transaction object state 5, transaction object state digest value 6 is a digest of transaction object state 6, transaction object state digest value 7 is a digest of transaction object state 7, and transaction object state digest value 8 is a digest of transaction object state 8.

[0391] In step 3420, a second summary tree is generated. The bottom-level node of the second summary tree is a summary of the status of each transaction object when the acquisition request is received. Other nodes in the first summary tree, except for the bottom-level node, are generated by performing summary operations on several adjacent nodes at the next lower level of other nodes until the second root node at the top level is generated.

[0392] According to embodiments of this disclosure, the second digest tree refers to a tree-like data structure that uses the digest of the state of each transaction object at the time of receiving the retrieval request as the lowest-level node. In the second digest tree, nodes other than the lowest-level node are generated by concatenating several adjacent nodes at the next lower level and performing digest operations. The second root node refers to the root node in the second digest tree, which can be understood as the final digest obtained by concatenating the digests of the states of all transaction objects at the time of receiving the retrieval request.

[0393] For example, refer to Figure 35 Transaction object state summary values ​​5 and 6 are adjacent, and transaction object state summary values ​​7 and 8 are adjacent. After performing a summary operation on transaction object state summary values ​​5 and 6, transaction object state summary value 56 is obtained. After performing a summary operation on transaction object state summary values ​​7 and 8, transaction object state summary value 78 is obtained. At this point, transaction object state summary values ​​56 and 78 are adjacent. After performing a summary operation on transaction object state summary values ​​56 and 78, transaction object state summary value 5678 is obtained. It can be understood that transaction object state summary value 5678 is the final summary obtained after cascading transaction object state summary values ​​5, 6, 7, and 8, and transaction object state summary value 5678 is the second root node of the second summary tree.

[0394] Furthermore, the integrity of the state of each transaction object in the blockchain can be verified through the second root node of the second digest tree. In the second digest tree, modification of the digest of any node will cause a change in the digest of the second root node and the digests of the nodes connected to the node whose digest was modified. By tracing the nodes whose digests have changed in the second digest tree, the node whose digest was initially modified can be quickly located. For example, suppose... Figure 35 When the state 6 of a transaction object is modified, not only will the transaction object state summary value 6 change, but the transaction object state summary values ​​56 and 5678 will also change. Starting from the second root node of the second summary tree, tracing back to the node where the summary is changed, the transaction object state summary value 6 can be quickly located, thus confirming that the transaction object state 6 has been modified.

[0395] In step 3430, a second general summary is determined based on the second root node.

[0396] According to embodiments of this disclosure, the second root node in the second summary tree is the second total summary. For example... Figure 35 As shown, the second root node of the second summary tree is the transaction object status summary value 5678, and the transaction object status summary value 5678 is the second total summary.

[0397] The blockchain ledger program in the embodiments described in steps 3410 to 3430 above can construct the lowest-level node of the second digest tree based on the digest of the transaction object state when the retrieval request is received, and perform concatenation and digest operations on the lowest-level nodes of the second digest tree until the uppermost second root node is generated, thus obtaining the second digest tree. Based on the second root node of the second digest tree, the second total digest can be determined. Since any modification to the digest of any node in the second digest tree will cause a change in the second total digest, the state of each transaction object in the blockchain can be efficiently verified based on the second total digest, verifying whether the state of any transaction object in the blockchain has changed or been modified.

[0398] Detailed description of step 350

[0399] Step 350: In response to the consistency between the first and second general digests, return the target transaction object status to the target terminal.

[0400] In some embodiments, the trusted execution environment has a built-in virtual machine, refer to Figure 36 Step 350 includes:

[0401] Step 3610: Use the first total summary as the target context of the built-in virtual machine, and make the built-in virtual machine compare the second total summary with the target context. In response to the second total summary being consistent with the target context, return the target transaction object status to the target terminal.

[0402] Step 3610 is described in detail below:

[0403] According to embodiments of this disclosure, a virtual machine is a computer system simulated by software that can run a complete operating system and applications in a completely isolated environment. Virtual machines achieve hardware resource sharing and reuse by utilizing the physical resources of the host system. In this embodiment, a built-in virtual machine refers to a virtual machine set up within the trusted execution environment of the target blockchain node, such as... Figure 37 As shown.

[0404] Furthermore, the context refers to the environment in which a process executes, including files opened by the process, various state information, and memory information. It is understood that the initial stage of the built-in virtual machine's operation requires configuring an initial context, and the target context refers to the initial context configured for the built-in virtual machine. This embodiment of the disclosure utilizes a trusted execution environment to decrypt the first ciphertext, recover the first total digest, and then uses the first total digest as the target context of the built-in virtual machine, enabling the built-in virtual machine to be managed and scheduled based on the first total digest.

[0405] According to embodiments of this disclosure, after the built-in virtual machine obtains the target transaction object state and the second total digest by calling the blockchain ledger program, it compares the second total digest with the target context. Specifically, it compares the second total digest with the first total digest to determine whether the total digest of each transaction object state at the time the retrieval request is received is consistent with the total digest of each transaction object state after the transaction execution in the target block. This determines the credibility of the target transaction object state returned to the built-in virtual machine by the blockchain ledger program. If the second total digest is consistent with the target context, it indicates that the target transaction object state is credible, and the built-in virtual machine can then return the target transaction object state to the target terminal.

[0406] According to another embodiment of this disclosure, whenever the built-in virtual machine calls the blockchain ledger program, the blockchain ledger program provides a Merkel proof. The Merkel proof includes not only the state of the target transaction object, but also the transaction object states of the nodes adjacent to the node of the target transaction object state, multiple transaction object states of adjacent groups of the node of the target transaction object state, and multiple transaction object states of adjacent branches of the node of the target transaction object state. By hashing the above data, a second total digest can be calculated. If the second total digest is consistent with the target context, it indicates that the target transaction object state is trustworthy. At this time, the built-in virtual machine can return the target transaction object state to the target terminal.

[0407] In the embodiment of step 3610 described above, the built-in virtual machine uses the first total digest as its target context, enabling the built-in virtual machine to be managed and scheduled based on the first total digest. Further, the built-in virtual machine compares the second total digest with the target context. If the second total digest and the target context are consistent, it indicates that the target transaction object state is trustworthy and has not been tampered with. The target transaction object state can then be returned to the target terminal, thereby ensuring the security of transaction object state queries.

[0408] In one embodiment, reference is made to Figure 38 Step 350 includes:

[0409] Step 3810: Sign the target transaction object state using the private key of the trusted execution environment to obtain the target signature;

[0410] Step 3820: Return the target signature along with the target transaction object status to the target terminal so that the target terminal can use the target signature to verify the target transaction object status.

[0411] Steps 3810 and 3820 are described in detail below:

[0412] In step 3810, the target transaction object state is signed using the private key of the trusted execution environment to obtain the target signature.

[0413] Understandably, signing data is a technique to ensure data integrity and verify the sender's identity. Digital signature algorithms include hash signatures, Digital Signature Algorithms (DSA), and Elliptic Curve Digital Signature Algorithms (ECDSA), among others. In practice, different digital signature algorithms can be selected to sign data depending on the specific application scenario.

[0414] In the embodiments of this disclosure, the target signature refers to a digital signature obtained by signing the state of a target transaction object using the private key of a trusted execution environment. By using the private key of the trusted execution environment to sign the state of the target transaction object, the data integrity of the target transaction object state can be ensured, enabling the target terminal receiving the target transaction object state to verify the sender's identity through the target signature.

[0415] Furthermore, the process by which the Trusted Execution Environment (TEE) signs the state of the target transaction object using its private key includes: first, using a hash function to hash the state of the target transaction object, generating a fixed-length message digest; then, encrypting the message digest using the TEE's private key to generate the target signature. This process can be represented as: Sig = Enclave.Sign(TEE_EVM.Return); where Sig represents the target signature; TEE_EVM.Return represents the state of the target transaction object obtained by the built-in virtual machine; and Enclave.Sign(TEE_EVM.Return) represents encrypting the message digest corresponding to the state of the target transaction object using the TEE's private key.

[0416] In step 3820, the target signature, along with the target transaction object status, is returned to the target terminal so that the target terminal can use the target signature to verify the target transaction object status.

[0417] According to embodiments of this disclosure, referring to Figure 39 After generating the target signature, the trusted execution environment returns the target signature along with the target transaction object state to the target terminal. This process can be represented as: Response =<TEE_EVM.Return,Sig> Where Response represents the data returned by the trusted execution environment to the target terminal; TEE_EVM.Return represents the state of the target transaction object obtained by the built-in virtual machine; and Sig represents the target signature.

[0418] Understandably, during the communication process where the trusted execution environment returns the target signature and the target transaction object status to the target terminal, the target transaction object status may be tampered with by the communication service provider. Therefore, after receiving the target signature and target transaction object status returned by the trusted execution environment, the target terminal also needs to verify the target transaction object status using the target signature to ensure the data integrity, trustworthiness, and sender's identity of the target transaction object status.

[0419] The specific method for "the target terminal to verify the state of the target transaction object using the target signature" will be described in detail below.

[0420] In the embodiments of steps 3810 to 3820 above, the trusted execution environment can use the private key to sign the state of the target transaction object to obtain the target signature, thereby ensuring the data integrity of the target transaction object state. This allows the target terminal receiving the target transaction object state to verify the sender's identity through the target signature, thus ensuring the trustworthiness of the target transaction object state.

[0421] In one embodiment, reference is made to Figure 40 Prior to step 310, the blockchain processing method further includes:

[0422] Step 4010: Publish the public key of the trusted execution environment;

[0423] Step 3820 includes:

[0424] Step 4020: Use the public key to decrypt the target signature and obtain the decryption result;

[0425] Step 4030: Perform a digest operation on the state of the target transaction object using a predetermined digest algorithm to obtain a digest of the state of the target transaction object;

[0426] Step 4040: If the decryption result matches the state digest of the target transaction object, the verification is successful.

[0427] Steps 4010 to 4040 are described in detail below:

[0428] In step 4010, the public key of the trusted execution environment is published.

[0429] According to embodiments of this disclosure, when the trusted execution environment returns the state of the target transaction object to the target terminal, an asymmetric encryption algorithm can be used to sign the state of the target transaction object. That is, the key used by the trusted execution environment to encrypt the message digest of the target transaction object state is different from the key used by the target terminal to decrypt the target signature. Therefore, the target blockchain node needs to publish the public key of the trusted execution environment to the target terminal before extracting the first total digest from the first block header of the target block to be recorded in the blockchain using the trusted execution environment. The public key of the trusted execution environment is the key used by the target terminal to decrypt the target signature.

[0430] It is understandable that each target blockchain node's trusted execution environment (TEE) possesses a unique public key. The public key of the trusted execution environment published by the target blockchain to the target terminal can be represented as: TEE_Pubkeys = {TEE_Pubkey...} i}; TEE_Pubkeys represents the set of public keys returned to the target terminal by multiple different target blockchain nodes; TEE_Pubkey i This represents the public key returned by the i-th target blockchain node to the target terminal.

[0431] In step 4020, the target signature is decrypted using the public key to obtain the decryption result.

[0432] According to embodiments of this disclosure, after receiving the target signature and target transaction object status returned by the target blockchain node, the target terminal, in order to verify the data integrity of the target transaction object status, first needs to use the public key to decrypt the target signature, obtaining a message digest generated by the trusted execution environment using a hash function to hash the target transaction object status. It can be understood that this message digest generated by the trusted execution environment using a hash function to hash the target transaction object status is the decryption result.

[0433] In step 4030, a digest operation is performed on the target transaction object state using a predetermined digest algorithm to obtain a digest of the target transaction object state.

[0434] According to the embodiments of this invention, the predetermined digest algorithm refers to a hash function. The predetermined digest algorithm can be Message-Digest Algorithm 5 (MD5), Secure Hash Algorithm 1 (SHA-1), or other hash functions. To verify the data integrity of the target transaction object's state, after receiving the target signature and target transaction object state returned by the target blockchain node, the target terminal also needs to perform a digest operation on the target transaction object state using the predetermined digest algorithm to generate a message digest. It can be understood that this message digest generated by the target terminal using the predetermined digest algorithm to perform a digest operation on the target transaction object state is the target transaction object state digest.

[0435] In step 4040, if the decryption result matches the state digest of the target transaction object, the verification is successful.

[0436] According to embodiments of this disclosure, the decryption result is a message digest generated by the trusted execution environment using a hash function to hash the state of the target transaction object. The state of the target transaction object is a message digest generated by the target terminal using a predetermined digest algorithm to digest the state of the target transaction object. If the decryption result matches the digest of the state of the target transaction object, it indicates that the state of the target transaction object has data integrity and is trustworthy, has not been tampered with, and the target terminal has successfully verified the state of the target transaction object.

[0437] In the embodiments described in steps 4010 to 4040 above, after receiving the target signature and target transaction object status returned by the target blockchain node, the target terminal decrypts the target signature using the public key pre-published by the trusted execution environment to obtain the decryption result. Simultaneously, a digest calculation is performed on the target transaction object status using a predetermined digest algorithm to obtain a digest of the target transaction object status. If the decryption result matches the digest of the target transaction object status, it indicates that the target transaction object status has data integrity, and the verification is successful. The above method ensures the trustworthiness of the target transaction object status.

[0438] Description of apparatus and devices according to embodiments of this disclosure

[0439] It is understood that 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.

[0440] It should be noted that in various specific embodiments of this application, when processing data related to object characteristics, such as object attribute information or sets of attribute information, is required, the object's permission or consent 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 require obtaining 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 these embodiments be acquired.

[0441] Figure 41 This is a schematic diagram of the structure of the blockchain processing device 4100 provided in this embodiment. The blockchain processing device 4100 is executed on a target blockchain node. The target blockchain node has a trusted execution environment, a blockchain ledger program, and encrypted storage space. The blockchain processing device 4100 includes:

[0442] The first response unit 4110 is used to respond to the generation of a target block to be recorded in the blockchain, using a trusted execution environment to extract a first total digest from the first block header of the target block, perform encryption processing based on the first total digest to obtain a first ciphertext, and store it in the ciphertext storage space. The target block includes one or more transactions, and the first total digest refers to the total digest of the state of each transaction object after the execution of one or more transactions.

[0443] Recording unit 4120 is used to record the target block on the blockchain;

[0444] The second response unit 4130 is used to respond to a request from the target terminal to obtain the state of the target transaction object after one or more transactions have been executed, and to obtain the first ciphertext from the ciphertext storage space using a trusted execution environment, and to perform decryption processing based on the first ciphertext to obtain the recovered first total digest.

[0445] The acquisition unit 4140 is used to acquire the state of the target transaction object and the second total summary from the blockchain accounting program, wherein the second total summary refers to the total summary of the state of each transaction object when the target blockchain node receives the acquisition request;

[0446] The third response unit 4150 is used to return the target transaction object status to the target terminal in response to the first general summary being consistent with the second general summary.

[0447] Optionally, the first response unit 4110 is specifically used for:

[0448] Determine a summary of the state of each transaction object after all transactions in the target block have been executed;

[0449] Generate the first summary tree, where the bottom-level node of the first summary tree is a summary of the state of each transaction object. Other nodes in the first summary tree, except for the bottom-level node, are generated by performing a summary operation on several adjacent nodes at the next lower level of other nodes, until the first root node of the top level is generated.

[0450] Based on the first root node, determine the first overall summary.

[0451] Optionally, the first response unit 4110 is specifically used for:

[0452] Obtain the first block header of the target block and extract the third total digest from the first block header. The third total digest is a summary of the state of each transaction object in the target block before the transaction is executed.

[0453] Obtain the second block header of the block preceding the target block, and extract the fourth total digest from the second block header. The fourth total digest is a summary of the state of each transaction object after the execution of the transaction in the previous block.

[0454] If the third and fourth general digests are consistent, the first block header is determined to be valid, and the first general digest is extracted from the first block header.

[0455] Optionally, the first response unit 4110 is specifically used for:

[0456] In response to the consistency between the third and fourth general digests, the consensus protocol version number is obtained from the first block header;

[0457] If the obtained consensus protocol version number belongs to the predetermined version number set, the first block header is determined to be valid.

[0458] Optionally, the first response unit 4110 is specifically used for:

[0459] Obtain the first block identifier of the target block;

[0460] Integrate the first general summary and the first block identifier to obtain the first integrated body;

[0461] The first integrated entity is encrypted to obtain the first ciphertext;

[0462] The first ciphertext is stored in the ciphertext storage space in correspondence with the first block identifier.

[0463] Optionally, the second response unit 4130 is specifically used for:

[0464] Obtain the first block identifier from the retrieval request;

[0465] Retrieve the second ciphertext stored in the ciphertext storage space, which corresponds to the identifier of the first block;

[0466] Decryption is performed based on the second ciphertext to obtain the second integrated entity;

[0467] From the second integrated body, obtain the fifth overall summary and the third block identifier;

[0468] In response to the fact that the third block identifier is consistent with the first block identifier, the fifth total digest is determined as the recovered first total digest.

[0469] Optionally, the first response unit 4110 is specifically used for:

[0470] The first overall summary and the first block identifier are interleaved according to the target interleaving rules to obtain the first integrated body;

[0471] The second response unit 4130 is specifically used for:

[0472] The second integrator is de-interleaved according to the target interleaving rules to obtain the fifth overall summary and the third block identifier.

[0473] Optionally, the first response unit 4110 is specifically used for:

[0474] Extract the target block type from the first block header;

[0475] Determine the target interleaving rules based on the target block type;

[0476] The first general summary and the first block identifier are interleaved according to the determined target interleaving rules to obtain the first integrated body.

[0477] Optionally, the second response unit 4130 is specifically used for:

[0478] From the retrieval request, obtain the target block type of the target block;

[0479] Determine the target interleaving rules based on the target block type;

[0480] The second integrator is de-interleaved according to the defined target interleaving rules to obtain the fifth overall summary and the third block identifier.

[0481] Optionally, the first response unit 4110 is specifically used for:

[0482] Using the private key of the trusted execution environment, the first integrated body is symmetrically encrypted to obtain the first ciphertext;

[0483] The second response unit 4130 is specifically used for:

[0484] Using the private key, symmetric decryption is performed based on the second ciphertext to obtain the second integrated entity.

[0485] Optionally, the trusted execution environment has multiple private keys corresponding to multiple block types;

[0486] The first response unit 4110 is specifically used for:

[0487] Obtain the target block type from the first block header; use the private key corresponding to the target block type to perform symmetric encryption on the first integrated block to obtain the first ciphertext;

[0488] The second response unit 4130 is specifically used for:

[0489] Obtain the target block type from the retrieval request; use the private key corresponding to the target block type to perform symmetric decryption based on the second ciphertext to obtain the second integrated block.

[0490] Optionally, the first response unit 4110 is specifically used for:

[0491] The first general summary and the first block identifier are concatenated into a tuple using a predetermined delimiter, forming the first integrated body;

[0492] The second response unit 4130 is specifically used for:

[0493] The second concatenation is parsed using a predetermined delimiter to obtain the fifth overall summary and the third block identifier.

[0494] Optionally, the blockchain processing device further includes a fourth response unit, which is specifically used for:

[0495] The system receives a composite retrieval request from the target terminal for the composite state of the target block, where the composite state is associated with the states of multiple target transaction objects; it uses a trusted execution environment to retrieve the first ciphertext from the ciphertext storage space; it performs decryption processing based on the first ciphertext to obtain the recovered first total digest; it retrieves the states of multiple target transaction objects and a sixth total digest from the blockchain ledger program; in response to the consistency between the first and sixth total digests, it generates a composite state using the retrieved states of multiple target transaction objects and returns it to the target terminal, where the sixth total digest refers to the total digest of the states of each transaction object when the target blockchain node receives the composite retrieval request.

[0496] Optionally, the composite acquisition request includes a composite state function, which indicates the relationship between the composite state and the states of multiple target transaction objects.

[0497] The fourth response unit is specifically used for:

[0498] Substitute the states of multiple target transaction objects obtained into the composite state function to obtain the composite state.

[0499] Optionally, the trusted execution environment has a built-in virtual machine;

[0500] The third response unit 4150 is specifically used for:

[0501] The first total summary is used as the target context of the built-in virtual machine, which then compares the second total summary with the target context. In response to the second total summary matching the target context, the virtual machine returns the target transaction object status to the target terminal.

[0502] Optionally, the third response unit 4150 is specifically used for:

[0503] The target transaction object's state is signed using the private key of the trusted execution environment to obtain the target signature;

[0504] The target signature, along with the target transaction object state, is returned to the target terminal so that the target terminal can use the target signature to verify the target transaction object state.

[0505] Optionally, the blockchain processing device further includes a publishing unit, which is specifically used for:

[0506] Publish the public key of the trusted execution environment;

[0507] The target terminal is specifically used for:

[0508] Using the public key, the target signature is decrypted to obtain the decryption result;

[0509] A digest operation is performed on the state of the target transaction object using a predetermined digest algorithm to obtain a digest of the state of the target transaction object;

[0510] If the decryption result matches the state digest of the target transaction object, the verification is successful.

[0511] Optionally, the acquisition unit 4140 is specifically used for:

[0512] Determine a summary of the state of each transaction object when the retrieval request is received;

[0513] Generate a second summary tree, where the bottommost node of the second summary tree is a summary of the state of each transaction object when the retrieval request is received. Other nodes in the first summary tree, except for the bottommost node, are generated by performing a summary operation on several adjacent nodes at the next lower level of other nodes, until the second root node at the top level is generated.

[0514] Based on the second root node, determine the second overall summary.

[0515] Reference Figure 42 , Figure 42 To implement the structural block diagram of the terminal portion of the blockchain processing method according to this embodiment, the terminal includes: a radio frequency (RF) circuit 4210, a memory 4215, an input unit 4230, a display unit 4240, a sensor 4250, an audio circuit 4260, a wireless fidelity (WiFi) module 4270, a processor 4280, and a power supply 4290, etc. Those skilled in the art will understand that... Figure 42 The terminal structure shown does not constitute a limitation on mobile phones or computers and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0516] The RF circuit 4210 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 4280; in addition, it transmits uplink data to the base station.

[0517] The memory 4215 can be used to store software programs and modules. The processor 4280 executes various functional applications and data processing of the content terminal by running the software programs and modules stored in the memory 4215.

[0518] The input unit 4230 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 content terminal. Specifically, the input unit 4230 may include a touch panel 4231 and other input devices 4232.

[0519] Display unit 4240 can be used to display input or provided information, as well as various menus of the content terminal. Display unit 4240 may include display panel 4241.

[0520] Audio circuitry 4260, speaker 4261, and microphone 4262 provide an audio interface.

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

[0522] 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 invention can be applied to various scenarios, including but not limited to cloud service resource pool status queries and cloud service IoT device status queries.

[0523] Figure 43 This is a partial structural block diagram of a server for implementing the blockchain processing method of this disclosure. The server can vary significantly due to different configurations or performance, and may include one or more Central Processing Units (CPUs) 4322 (e.g., one or more processors) and a memory 4332, and one or more storage media 4330 (e.g., one or more mass storage devices) for storing application programs 4342 or data 4344. The memory 4332 and storage media 4330 can be temporary or persistent storage. The program stored in the storage media 4330 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 4322 may be configured to communicate with the storage media 4330 and execute the series of instruction operations in the storage media 4330 on the server.

[0524] The server may also include one or more power supplies 4326, one or more wired or wireless network interfaces 4350, one or more input / output interfaces 4358, and / or one or more operating systems 4341, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

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

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

[0527] 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.

[0528] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the foregoing drawings are used to distinguish similar terms and are not necessarily used to describe a particular order or sequence. It should be understood that such use of data can be interchanged where appropriate so that 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.

[0529] It should be understood that in this disclosure, "at least one item" refers to one or more items, and "more than one item" refers to two or more items. "And / or" is used to describe the relationship between related content, 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 content 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.

[0530] 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.

[0531] In the 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. The couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0532] 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.

[0533] 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.

[0534] 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 130, 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 a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

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

[0536] 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, Executed by a target blockchain node, the target blockchain node having a trusted execution environment, a blockchain ledger program, and encrypted storage space, the blockchain processing method includes: In response to generating a target block to be recorded in the blockchain, the trusted execution environment is used to extract a first total digest from the first block header of the target block, and the first total digest is encrypted to obtain a first ciphertext, which is then stored in the ciphertext storage space. The target block includes one or more transactions, and the first total digest refers to a total digest of the state of each transaction object after the one or more transactions are executed. Record the target block onto the blockchain; In response to a request from the target terminal to obtain the state of the target transaction object after the execution of the one or more transactions, the trusted execution environment is used to obtain the first ciphertext from the ciphertext storage space, and decryption is performed based on the first ciphertext to obtain the recovered first total digest. Obtain the state of the target transaction object and a second total summary from the blockchain ledger program, wherein the second total summary refers to the total summary of the state of each transaction object when the target blockchain node receives the acquisition request; In response to the first total digest being consistent with the second total digest, the status of the target transaction object is returned to the target terminal.

2. The blockchain processing method according to claim 1, characterized in that, The first overall summary is generated by the blockchain ledger program in the following manner: Determine a summary of the state of each transaction object after all transactions in the target block have been executed; Generate a first summary tree, wherein the bottom-level node of the first summary tree is the summary of the state of each transaction object, and the other nodes in the first summary tree, except for the bottom-level node, are generated by performing a summary operation on several adjacent nodes at the next lower level of the other nodes, until the first root node of the top level is generated. Based on the first root node, the first overall summary is determined.

3. The blockchain processing method according to claim 1 or 2, characterized in that, Extracting the first total digest from the first block header of the target block includes: Obtain the first block header of the target block, and extract the third total digest from the first block header, wherein the third total digest is a total digest of the state of each transaction object in the target block before the transaction is executed; Obtain the second block header of the previous block of the target block, and extract the fourth total digest from the second block header, wherein the fourth total digest is a total digest of the state of each transaction object after the execution of the transaction in the previous block; If the third total digest is consistent with the fourth total digest, the first block header is determined to be valid, and the first total digest is extracted from the first block header.

4. The blockchain processing method according to claim 3, characterized in that, The step of determining that the first block header is valid if the third total digest is consistent with the fourth total digest includes: In response to the third total digest being consistent with the fourth total digest, the consensus protocol version number is obtained from the first block header; If the obtained consensus protocol version number belongs to a predetermined set of version numbers, the first block header is determined to be valid.

5. The blockchain processing method according to any one of claims 1-4, characterized in that, The step of encrypting the first total digest to obtain the first ciphertext and storing it in the ciphertext storage space includes: Obtain the first block identifier of the target block; Integrate the first overall summary and the first block identifier to obtain the first integrated body; The first integrated body is encrypted to obtain the first ciphertext; The first ciphertext is stored in the ciphertext storage space in correspondence with the first block identifier.

6. The blockchain processing method according to claim 5, characterized in that, The step of retrieving the first ciphertext from the ciphertext storage space, and performing decryption processing based on the first ciphertext to obtain the recovered first total digest includes: Obtain the first block identifier from the acquisition request; Retrieve the second ciphertext corresponding to the first block identifier from the ciphertext storage space; The second ciphertext is decrypted to obtain the second integrated entity; From the second consolidation, obtain the fifth overall summary and the third block identifier; In response to the fact that the third block identifier is consistent with the first block identifier, the fifth total digest is determined to be the recovered first total digest.

7. The blockchain processing method according to claim 6, characterized in that, The step of integrating the first total digest and the first block identifier to obtain the first integrated body includes: interleaving the first total digest and the first block identifier according to a target interleaving rule to obtain the first integrated body; Obtaining the fifth total digest and the third block identifier from the second concatenation includes: deinterleaving the second concatenation according to the target interleaving rule to obtain the fifth total digest and the third block identifier.

8. The blockchain processing method according to claim 7, characterized in that, The step of interleaving the first total digest and the first block identifier according to the target interleaving rule to obtain the first integrated body includes: Extract the target block type of the target block from the first block header; The target interleaving rule is determined based on the target block type; The first overall summary and the first block identifier are interleaved according to the determined target interleaving rules to obtain the first integrated body.

9. The blockchain processing method according to claim 7, characterized in that, The step of deinterleaving the second concatenation according to the target interleaving rule to obtain the fifth total digest and the third block identifier includes: From the acquisition request, obtain the target block type of the target block; The target interleaving rule is determined based on the target block type; The second concatenation is de-interleaved according to the determined target interleaving rules to obtain the fifth total digest and the third block identifier.

10. The blockchain processing method according to claim 6, characterized in that, The step of encrypting the first integrated entity to obtain the first ciphertext includes: using the private key of the trusted execution environment to perform symmetric encryption on the first integrated entity to obtain the first ciphertext; The step of decrypting the second ciphertext to obtain the second integrated entity includes: using the private key to perform symmetric decryption based on the second ciphertext to obtain the second integrated entity.

11. The blockchain processing method according to claim 6, characterized in that, The step of integrating the first total digest and the first block identifier to obtain the first integrated body includes: concatenating the first total digest and the first block identifier into a tuple using a predetermined delimiter to obtain the first integrated body; Obtaining the fifth overall digest and the third block identifier from the second consolidation includes: parsing the second consolidation into tuples based on the predetermined delimiter to obtain the fifth overall digest and the third block identifier.

12. The blockchain processing method according to any one of claims 1-11, characterized in that, After recording the target block on the blockchain, the blockchain processing method further includes: The system receives a composite retrieval request from the target terminal for the composite state of the target block, wherein the composite state is associated with the states of multiple target transaction objects; using the trusted execution environment, it retrieves the first ciphertext from the ciphertext storage space; decrypts the first ciphertext to obtain the recovered first total digest; retrieves the states of the multiple target transaction objects and a sixth total digest from the blockchain ledger program; in response to the first total digest being consistent with the sixth total digest, it generates the composite state using the retrieved states of the multiple target transaction objects and returns it to the target terminal, wherein the sixth total digest refers to the total digest of the states of each transaction object when the target blockchain node receives the composite retrieval request.

13. The blockchain processing method according to claim 12, characterized in that, The composite acquisition request includes a composite state function, which indicates the relationship between the composite state and the state changes of the multiple target transaction objects. The step of generating the composite state using the acquired states of the multiple target transaction objects includes: substituting the acquired states of the multiple target transaction objects into the composite state function to obtain the composite state.

14. The blockchain processing method according to any one of claims 1-13, characterized in that, The trusted execution environment has a built-in virtual machine; The step of returning the target transaction object status to the target terminal in response to the first total digest being consistent with the second total digest includes: The first total summary is used as the target context of the built-in virtual machine, and the built-in virtual machine compares the second total summary with the target context. In response to the second total summary being consistent with the target context, the target virtual machine returns the target transaction object status to the target terminal.

15. The blockchain processing method according to any one of claims 1-14, characterized in that, The step of returning the status of the target transaction object to the target terminal includes: The target transaction object state is signed using the private key of the trusted execution environment to obtain the target signature; The target signature, along with the target transaction object status, is returned to the target terminal so that the target terminal can use the target signature to verify the target transaction object status.

16. The blockchain processing method according to claim 15, characterized in that, Before extracting a first total digest from the first block header of the target block using the trusted execution environment in response to generating a target block to be recorded in the blockchain, the blockchain processing method further includes: publishing the public key of the trusted execution environment; The target terminal uses the target signature to verify the state of the target transaction object, including: Using the public key, the target signature is decrypted to obtain the decryption result; A digest operation is performed on the state of the target transaction object using a predetermined digest algorithm to obtain a digest of the target transaction object's state. If the decryption result matches the state digest of the target transaction object, the verification is successful.

17. A blockchain processing device, characterized in that, Executed on a target blockchain node, the target blockchain node having a trusted execution environment, a blockchain ledger program, and encrypted storage space, the blockchain processing device comprising: The first response unit is configured to respond to the generation of a target block to be recorded in the blockchain, and to extract a first total digest from the first block header of the target block using the trusted execution environment, and to perform encryption processing based on the first total digest to obtain a first ciphertext, which is then stored in the ciphertext storage space. The target block includes one or more transactions, and the first total digest refers to a total digest of the state of each transaction object after the one or more transactions are executed. A recording unit is used to record the target block onto the blockchain; The second response unit is used to respond to a request from the target terminal to obtain the state of the target transaction object after the execution of the one or more transactions, and to obtain the first ciphertext from the ciphertext storage space using the trusted execution environment, and to perform decryption processing based on the first ciphertext to obtain the recovered first total digest. The acquisition unit is used to acquire the state of the target transaction object and a second total summary from the blockchain accounting program, wherein the second total summary refers to the total summary of the state of each transaction object when the target blockchain node receives the acquisition request; The third response unit is used to return the status of the target transaction object to the target terminal in response to the first total digest being consistent with the second total digest.

18. An electronic device comprising a memory and a processor, the memory storing 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, characterized in that, The computer program is read and executed by the processor of the computer device, causing the computer device to perform the blockchain processing method according to any one of claims 1 to 16.

Images