Data processing method, apparatus and device

Abstract

The application discloses a data processing method, device and equipment. The method is executed by a trusted execution node. The trusted execution node refers to a device located outside a blockchain network and internally provided with a trusted execution environment. The trusted execution environment is a security area isolated from an operating system of the trusted execution node. The method comprises the following steps: receiving a service request initiated by a client, wherein the service request carries a transaction; packing the transaction carried by the service request into a target block in the trusted execution environment and executing the target block to obtain an execution result; generating block data by using the target block and the execution result, and sending the block data to consensus nodes in the blockchain network, so that the consensus nodes in the blockchain network reach a consensus on the block data, and then store the block data into the blockchain; the method can reduce the calculation pressure of the blockchain network, improve the stability of the blockchain network, reduce the hardware configuration requirement of the consensus nodes in the blockchain network, and save the hardware cost of the blockchain network.

Description

Technical Field

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

[0002] In existing blockchain systems, there are typically clients located outside the blockchain network and multiple nodes located within the blockchain network. Generally, an object can initiate a business request to the blockchain network through a client to use the corresponding service. After receiving the business request, a node in the blockchain network broadcasts the business request to every node. Each node in the blockchain network, upon receiving the business request, responds to the business request to obtain the corresponding block data. After reaching a consensus on the block data, the block data is stored in the corresponding blockchain. In other words, the entire response process for a business request initiated by a client needs to be executed by every node in the blockchain network. This not only leads to a large computational burden on the blockchain network, resulting in poor stability, but also results in high hardware configuration requirements for each node, leading to a large hardware cost for the blockchain network. Summary of the Invention

[0003] This application provides a data processing method, apparatus, and device that can reduce the computational pressure on blockchain networks, improve their stability, reduce the hardware configuration requirements for consensus nodes in blockchain networks, and save on the hardware costs of blockchain networks.

[0004] On one hand, embodiments of this application provide a data processing method, wherein the method is executed by a trusted execution node, the trusted execution node being a device located outside the blockchain network and having a built-in trusted execution environment, the trusted execution environment being a secure area isolated from the operating system of the trusted execution node; wherein, the method includes:

[0005] Receive a business request initiated by a client, the business request carrying a transaction;

[0006] In the trusted execution environment, the transaction carried by the business request is packaged into a target block, and the target block is executed in the trusted execution environment to obtain the execution result;

[0007] Block data is generated using the target block and the execution result, and then sent to the consensus nodes in the blockchain network. After the consensus nodes in the blockchain network reach a consensus on the block data, the block data is stored in the blockchain.

[0008] On one hand, embodiments of this application provide a data processing method, which is executed by any consensus node in a blockchain network, the method comprising:

[0009] The system receives block data generated by the trusted execution node. The block data includes a target block and an execution result. The target block is obtained by packaging the transaction carried by the transaction request initiated by the client in the trusted execution environment within the trusted execution node. The execution result is obtained by executing the target block in the trusted execution environment within the trusted execution node. The trusted execution node refers to a device located outside the blockchain network and equipped with a built-in trusted execution environment. The trusted execution environment within the trusted execution node is a secure area isolated from the operating system of the trusted execution node.

[0010] Consensus processing is performed on the block data, and after consensus is reached on the block data, the block data is stored in the blockchain.

[0011] On one hand, this application provides a data processing apparatus that operates within a trusted execution node. The trusted execution node refers to a device located outside the blockchain network and equipped with a built-in trusted execution environment, which is a secure area isolated from the operating system of the trusted execution node. The apparatus includes:

[0012] The receiving unit is used to receive a business request initiated by a client, wherein the business request carries a transaction.

[0013] The processing unit is configured to package the transactions carried by the business request into a target block in the trusted execution environment, and execute the target block in the trusted execution environment to obtain the execution result;

[0014] The processing unit is further configured to generate block data using the target block and the execution result;

[0015] The sending unit is used to send the block data to the consensus nodes in the blockchain network, so that after the consensus nodes in the blockchain network reach a consensus on the block data, the block data is stored in the blockchain.

[0016] On one hand, embodiments of this application provide a data processing apparatus, which operates in any consensus node in a blockchain network, and the apparatus includes:

[0017] A receiving unit is configured to receive block data generated by the trusted execution node. The block data includes a target block and an execution result. The target block is obtained by packaging the transaction carried by the transaction request initiated by the client in the trusted execution environment within the trusted execution node. The execution result is obtained by executing the target block in the trusted execution environment within the trusted execution node. The trusted execution node refers to a device located outside the blockchain network and equipped with a built-in trusted execution environment. The trusted execution environment within the trusted execution node is a secure area isolated from the operating system of the trusted execution node.

[0018] The processing unit is used to perform consensus processing on the block data, and after reaching a consensus on the block data, store the block data in the blockchain.

[0019] On one hand, embodiments of this application provide a first electronic device, characterized in that the first electronic device includes an input interface and an output interface, and further includes:

[0020] A processor, adapted to implement one or more instructions; and,

[0021] A computer storage medium storing one or more instructions adapted to be loaded by the processor and executed by the above-described data processing method.

[0022] On one hand, embodiments of this application provide a second electronic device, characterized in that the second electronic device includes an input interface and an output interface, and further includes:

[0023] A processor, adapted to implement one or more instructions; and,

[0024] A computer storage medium storing one or more instructions adapted to be loaded by the processor and executed by the above-described data processing method.

[0025] On one hand, embodiments of this application provide a computer storage medium, characterized in that the computer storage medium stores computer program instructions, which, when executed by a processor, are used to perform the aforementioned data processing method.

[0026] On one hand, embodiments of this application provide a computer program product, which includes a computer program stored in a computer storage medium; a processor of a first electronic device reads the computer program from the computer storage medium and executes the computer program, causing the first electronic device to perform the above-described data processing method.

[0027] On one hand, embodiments of this application provide another computer program product, which includes a computer program stored in a computer storage medium; the processor of the second electronic device reads the computer program from the computer storage medium and executes the computer program, causing the second electronic device to perform the above-described data processing method.

[0028] In this embodiment, a trusted execution node located outside the blockchain network and equipped with a built-in trusted execution environment can be used to partially respond to business requests initiated by clients. Specifically, the trusted execution node can receive business requests from clients; package the transactions carried by the business request into a target block within the trusted execution environment; execute the target block within the trusted execution environment to obtain the execution result; generate block data using the target block and the execution result; and then send the block data to the consensus nodes in the blockchain network. After the consensus nodes in the blockchain network reach a consensus on the block data, they store the block data in the blockchain. The processes involved in responding to business requests, such as packaging transactions and executing blocks, are executed by the trusted execution node outside the blockchain network, not by the consensus nodes in the blockchain network. The consensus nodes in the blockchain network store the block data, thus enabling off-chain computation and on-chain storage capabilities. This reduces the computational pressure on the blockchain network, thereby improving its stability. Furthermore, the reduced computational pressure lowers the hardware configuration requirements for the consensus nodes in the blockchain network, thereby saving on the hardware costs of the blockchain network. Furthermore, since the processes of packaging transactions and executing blocks occur within the trusted execution environment of trusted execution nodes, this environment is a secure zone isolated from the operating system of the trusted execution nodes. This protects the program code running within it from modification by other program code, ensuring that even if the target block and execution result are generated outside the blockchain network, they remain trustworthy. In summary, this reduces the computational burden on the blockchain network, thereby improving its stability. It also lowers the hardware requirements for consensus nodes in the blockchain network, thus saving on hardware costs. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 This is a schematic diagram of the structure of a block provided in an embodiment of this application;

[0031] Figure 2 This is a schematic diagram of the structure of a data processing system provided in an embodiment of this application;

[0032] Figure 3 This is a schematic diagram of the structure of a trusted execution node provided in an embodiment of this application;

[0033] Figure 4 This is a flowchart illustrating a data processing method provided in an embodiment of this application;

[0034] Figure 5 This is a schematic diagram illustrating the execution process of a first application in a trusted execution node, as provided in an embodiment of this application.

[0035] Figure 6 This is a flowchart illustrating another data processing method provided in an embodiment of this application;

[0036] Figure 7a This is a flowchart illustrating another data processing method provided in an embodiment of this application;

[0037] Figure 7b This is a schematic diagram illustrating a data processing system for processing business requests, as provided in an embodiment of this application.

[0038] Figure 8 This is a schematic diagram illustrating how a client verifies the trustworthiness of a trusted execution node, as provided in an embodiment of this application.

[0039] Figure 9 This is a schematic diagram illustrating another client-side verification of the trustworthiness of a trusted execution node, provided in an embodiment of this application.

[0040] Figure 10 This is a schematic diagram illustrating the review process of a target application provided in an embodiment of this application;

[0041] Figure 11 This is a schematic diagram illustrating a consensus node-based approach to handling trusted execution node failures, provided in an embodiment of this application.

[0042] Figure 12 This is a schematic diagram illustrating how a consensus node responds to a service request after switching to a standby node, as provided in an embodiment of this application.

[0043] Figure 13a This is a schematic diagram illustrating how to detect whether a trusted execution node has failed, as provided in an embodiment of this application.

[0044] Figure 13b This is a schematic diagram illustrating another method for detecting whether a trusted execution node has failed, provided in an embodiment of this application.

[0045] Figure 13cThis is a schematic diagram illustrating another method for detecting whether a trusted execution node has failed, provided in an embodiment of this application.

[0046] Figure 14 This is a schematic diagram illustrating how a data processing system, according to an embodiment of this application, handles business requests when a trusted execution node fails.

[0047] Figure 15 This is a schematic diagram illustrating how an existing blockchain system processes business requests, as provided in an embodiment of this application.

[0048] Figure 16 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0049] Figure 17 This is a schematic diagram of the structure of a first electronic device provided in an embodiment of this application;

[0050] Figure 18 This is a schematic diagram of another data processing device provided in an embodiment of this application;

[0051] Figure 19 This is a schematic diagram of the structure of a second electronic device provided in an embodiment of this application. Detailed Implementation

[0052] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0053] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer (P2P) transmission, consensus mechanisms, and encryption algorithms. Essentially, it is a decentralized database, a chain of data blocks linked together using cryptographic methods. These data blocks, also called blockchains, are essentially data structures used to record information. Each blockchain contains information about a batch of network transactions (i.e., data), used to verify the validity of the information (i.e., anti-counterfeiting) and to generate the next block. See also... Figure 1This is a schematic diagram of a block structure provided in an embodiment of this application. Each block includes the hash value of the transaction records stored in this block (the hash value of this block) and the hash value of the previous block. The blocks are connected through hash values ​​to form a blockchain. A network based on blockchain and peer-to-peer (P2P) networks can be called a blockchain network. A blockchain network can include multiple node devices (referred to as nodes). It should be understood that any node device (i.e., a node) in a blockchain network can be a terminal device or a server. Among them, terminal devices can be smartphones, tablets, laptops, desktop computers, etc., without limitation; servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms, without limitation.

[0054] Based on the above description, this application provides a data processing system; see also Figure 2This is a schematic diagram of the structure of a data processing system provided in an embodiment of this application. The data processing system may include at least: a client 21, a trusted execution node 22, and a blockchain network 23, wherein the blockchain network 23 may include one or more consensus nodes 231. The client 21 may be a terminal device or an application running on the terminal device; this embodiment of the application does not impose any limitations. Optionally, the application running on the terminal device may be a decentralized application (DAPP). A DAPP is an application developed based on blockchain technology. Unlike traditional centralized applications, a DAPP does not have a central server or administrator, but runs through smart contracts. This means that DAPPs have higher security, transparency, and reliability. A smart contract refers to a computer protocol that disseminates, verifies, or executes contracts in an information-based manner. Trusted execution node 22 refers to a device (i.e., a node) located outside the blockchain network and equipped with a built-in Trusted Execution Environment (TEE). The TEE of the Trusted Execution Node 22 is a secure area isolated from its operating system (System on Chip, SoC). Furthermore, the TEE is a secure area constructed on the computing platform (device) using hardware and software methods, ensuring the confidentiality and integrity of code and data loaded within it. Its goal is to ensure a task executes as expected, guaranteeing the confidentiality and integrity of the initial state and the runtime state. Consensus node 231 refers to a node in the blockchain network that executes consensus processing based on a consensus mechanism according to the smart contract. The consensus mechanism refers to a mechanism that verifies and confirms data in a short time through voting by special nodes (i.e., consensus nodes). Client 21, Trusted execution node 22, and blockchain network 23 can communicate directly or indirectly through wired or wireless communication; this application does not impose any restrictions on this.

[0055] Based on the aforementioned data processing system, this application provides a data processing scheme, the principle of which is roughly as follows: A client can initiate a business request to a trusted execution node, the business request carrying a transaction; after receiving the business request from the client, the trusted execution node packages the transaction carried by the business request into a target block in its built-in trusted execution environment, and executes the target block in the built-in trusted execution environment to obtain the execution result; the trusted execution node uses the target block and the corresponding execution result to generate block data, and sends the block data to the consensus nodes in the blockchain network; the consensus nodes in the blockchain network perform consensus processing on the block data, and after reaching a consensus on the block data, store the block data in the blockchain; this scheme points out that the processes involved in the response to the business request, such as packaging transactions and executing blocks, are executed by trusted execution nodes outside the blockchain network, and do not need to be executed by consensus nodes in the blockchain network, thus realizing off-chain computation and on-chain storage, reducing the computational pressure on consensus nodes in the blockchain network; and since the processes of packaging transactions and executing blocks are executed based on the trusted execution environment of the trusted execution node, the obtained target block and execution result can be guaranteed to be trustworthy.

[0056] It is worth noting that the transactions involved in this application embodiment can be understood as computer terminology transactions. A transaction includes data that needs to be submitted to the blockchain network, and one or more operations that need to be performed. Given that the term "transaction" is conventionally used in blockchain technology, this application embodiment follows this convention. When the above data processing scheme is applied to different business scenarios, the business request is a request generated in the corresponding business scenario, and the transaction is also adapted to the corresponding scenario. For example, if the business scenario is an insurance-related scenario, an exemplary business request could be a request to calculate the premium based on the insurance data, and the corresponding transaction could include the insurance data. Furthermore, the client can obtain the data required to initiate the business request, package the obtained data into a transaction, and initiate the business request to the trusted execution node based on the packaged transaction. Optionally, when the business request is initiated by an object holding the client through the client, the corresponding data can be the object's input.

[0057] In one embodiment, since a trusted execution node refers to a device located outside the blockchain network and having a built-in trusted execution environment, and the trusted execution environment of a trusted execution node is a secure area isolated from the operating system of the trusted execution node, a structure of a trusted execution node may include: a trusted execution environment, other areas (i.e., a normal execution environment), and hardware supporting the trusted execution node. The trusted execution node provides corresponding services based on the application running within it, to realize the relevant functions of receiving business requests and sending block data in the above data processing scheme (for ease of explanation, the application running in the trusted execution node and realizing the above functions in this embodiment is referred to as the first application); since the trusted execution environment is a secure area constructed by software and hardware methods on a computing platform (device), it can ensure that the code and data loaded in the secure area are protected in terms of confidentiality and integrity. Therefore, the part of the program code that needs to be protected in the first application running in the trusted execution node can be deployed in the trusted execution environment of the trusted execution node to realize trusted execution of the part of the program code that needs to be protected. The part of the program code of the first application deployed in the trusted execution environment can be referred to as the trusted part of the first application, and the part of the program code of the first application deployed in other areas can be referred to as the untrusted part of the first application. The trusted part of the first application can be called by the untrusted part, and after the trusted part finishes running, the corresponding call result is returned to the untrusted part. In the above data processing scheme, the program code used to implement processes such as packaging transactions and executing blocks can be deployed in the trusted execution environment of the trusted execution node. This ensures that the target block and execution result are obtained within the trusted execution environment of the trusted execution node, thereby guaranteeing the trustworthiness of the target block and execution result. For ease of explanation, the trusted portion of the first application running in the trusted execution node will be referred to as the target application in this embodiment. This target application can run in the trusted execution environment of the trusted execution node to implement processes such as packaging transactions and executing blocks. That is, it can package the transactions carried by the business request into a target block within the built-in trusted execution environment, execute the target block within the built-in trusted execution environment, and obtain the execution result.

[0058] Based on the above description of trusted execution nodes, see [link to relevant documentation]. Figure 3This is a schematic diagram of a trusted execution node provided in an embodiment of this application. The trusted execution node may include: a trusted execution environment, other areas (i.e., a normal execution environment), and hardware supporting the trusted execution node. A first application runs in the trusted execution node. The trusted execution environment of the trusted execution node may include the trusted part of the first application (i.e., the target application), and may also include the API (Application Programming Interface) interface of the trusted execution environment and a security system. The other areas may include the untrusted part of the first application, and may also include other modules, other API interfaces, and operating systems (such as Android, iOS, Windows, etc.). The hardware supporting the trusted execution node may include a video transmitter for communication, a central processing unit (CPU), a hard disk, etc. It should be understood that... Figure 2 This is merely one exemplary structure for a trusted execution node.

[0059] In one embodiment, since the above data processing scheme can be applied to various business scenarios, and the business requests required to be processed in different business scenarios may differ, the first application running in the trusted execution node can be an application adapted to the business scenario, used to process the business requests generated by the corresponding business scenario. Further optionally, the first application running in the trusted execution node can also be a node program. The untrusted part of the node program is used to implement proxy functions, that is, the untrusted part of the node program can send and receive data externally, and internally can call the trusted part of the node program. For the trusted part of the node program, virtual machine functionality can be used to hot-deploy various applications (i.e., applications adapted to various business scenarios can be hot-deployed). This allows the node program to process business requests generated by the corresponding business scenario by calling the hot-deployed application adapted to the corresponding business scenario, and return the processing result to the trusted part of the node program, which then sends it to the consensus node in the blockchain network through the untrusted part of the node program. In this case, the node program implements communication with the client and the blockchain network, and it is not necessary to send each Each application adapted to the business scenario communicates directly with the client and the blockchain network. Furthermore, when it's necessary to verify the trustworthiness of a trusted execution node, only the trusted portion of the node program needs to be verified. If the trusted portion of the node program is trustworthy, the trusted execution node is considered trustworthy. It's not necessary to verify each application adapted to the business scenario, and only if each application adapted to the business scenario is trustworthy can the trusted execution node be considered trustworthy. This makes verifying the trustworthiness of the trusted execution node simpler and more efficient. This is because the applications adapted to the business scenario are hot-deployed within the trusted portion of the node program using virtual machines. If the trusted portion of the node program is trustworthy, the hot-deployed application can be considered trustworthy, eliminating the need for repeated verification. The data processing scheme proposed in this application can be implemented based on the above two deployment methods.

[0060] It is particularly important to note that in the specific embodiments of this application, object-related data is involved. For example, when a business request initiated by a client is generated based on object input data, the object-related data refers to the object input data used to generate the business request. When the embodiments of this application are applied to specific products or technologies, permission or consent from the object is required, and the collection, use, and processing of related data must comply with local laws, regulations, and standards. Furthermore, during the collection, use, and processing of data, the relevant object can be notified through an interactive interface. Subsequent processing will only proceed after confirmation of permission to collect, use, or process the data is received on this interactive interface.

[0061] Based on the above data processing scheme and system, this application provides a data processing method. See also... Figure 4 This is a flowchart illustrating a data processing method provided in an embodiment of this application; it may include the following steps:

[0062] S401, the client initiates a service request to the trusted execution node.

[0063] In one embodiment, the business request can be a request generated in various business scenarios, and the business request can carry a transaction (also known as a transaction request). For example, if the business scenario is insurance-related, an exemplary business request could be a request to calculate the premium based on the insurance data, and the corresponding transaction could include the insurance data. Further optionally, the business request could also be a request to perform a data query, such as a request to query block data stored on the blockchain (also known as a query request). Furthermore, the client can obtain the data required to initiate the business request, package the obtained data into a transaction, and initiate the business request to the trusted execution node based on the packaged transaction. Optionally, when the business request is initiated by an object holding the client through the client, the corresponding data can be input from the object.

[0064] S402: The trusted execution node receives a business request initiated by the client, packages the transaction carried by the business request into a target block in the built-in trusted execution environment, and executes the target block in the built-in trusted execution environment to obtain the execution result.

[0065] In one embodiment, the specific execution process of the trusted execution node in executing the target block in the built-in trusted execution environment may differ depending on the business request. For example, if the business scenario is insurance-related and the business request is to calculate the premium based on the insurance data, the corresponding transaction may include the insurance data. In this case, the process of the trusted execution node executing the target block in the built-in trusted execution environment can be the process of executing the transaction in the target block, that is, calculating the premium based on the insurance data included in the transaction, and the calculated premium is used as the execution result of the target block.

[0066] Furthermore, the process described in step S402 can be executed by a first application running in the trusted execution node. This first application includes a trusted part (referred to as the target application) deployed in the trusted execution environment of the trusted execution node, and an untrusted part deployed in other areas. The trusted part can be used to perform processes such as packaging transactions and executing blocks. That is, it can be used to package the transactions carried by the business request into a target block in the built-in trusted execution environment, and execute the target block in the built-in trusted execution environment to obtain the execution result. The untrusted part can be used to implement proxy functions. That is, the untrusted part can send and receive data externally and call the trusted part internally. In other words, the untrusted part of the first application running in the trusted execution node can receive business requests initiated by clients and call the trusted part, that is, forward the transactions carried by the business request to the trusted part, so that the trusted part can package the transactions carried by the business request into a target block in the built-in trusted execution environment of the trusted execution node, and execute the target block in the built-in trusted execution environment to obtain the execution result.

[0067] S403, the trusted execution node generates block data using the target block and the corresponding execution results.

[0068] In one embodiment, the trusted execution node generates block data using the target block and the corresponding execution result. This can be executed within the built-in trusted execution environment or in other areas of the trusted execution node. This application embodiment does not impose limitations on this; the following embodiments will use execution within the built-in trusted execution environment as an example. Furthermore, this process can be executed based on a first application running in the trusted execution node. When the process is executed in the built-in trusted execution environment, it is based on the trusted portion of the first application in the trusted execution node; when the process is executed in other areas of the trusted execution node, it is based on the untrusted portion of the first application in the trusted execution node.

[0069] S404, the trusted execution node sends block data to the consensus nodes in the blockchain network.

[0070] In one embodiment, the trusted execution node sends block data to the consensus nodes in the blockchain network so that the consensus nodes can reach a consensus on the block data and then store the block data in the blockchain. The trusted execution node can send block data to every consensus node in the blockchain network, or it can send block data to some consensus nodes in the blockchain, so that the consensus nodes that receive the block data can broadcast the block data to other consensus nodes. This application embodiment does not impose limitations. For ease of explanation, the second implementation method will be used as an example in the following embodiments.

[0071] S405, consensus nodes in a blockchain network perform consensus processing on block data, and after reaching a consensus on the block data, store the block data in the blockchain.

[0072] In one embodiment, consensus nodes in a blockchain network process block data based on a consensus mechanism. This consensus mechanism refers to a mechanism that verifies and confirms data within a short time through voting by consensus nodes. When processing block data, consensus nodes in the blockchain network consider a consensus reached if the voting results of a majority of consensus nodes on the block data are consistent. Furthermore, after reaching a consensus on the block data, the consensus nodes store the block data in the blockchain, specifically in the corresponding ledger. This ledger provides functions for storing, querying, and modifying data generated in the data processing system, essentially functioning as a database (DB). Further, consensus nodes in the blockchain network can provide corresponding services based on applications running within them to achieve specific functions. For ease of explanation, this embodiment refers to the application running on the consensus nodes in the blockchain network and implementing the corresponding functions as a second application.

[0073] In one embodiment, various TEE technologies can be used to protect the confidentiality and integrity of code and data loaded in the trusted execution environment of a trusted execution node. The loaded code refers to the trusted portion of the first application in the trusted execution node, and the corresponding data refers to data related to the trusted portion. In other words, TEE technology enables the trusted portion of the first application in the trusted execution node to execute as expected (also known as achieving trusted execution). Optionally, TEE technologies may include, but are not limited to, Intel SGX technology, ARM TrustZone technology in security solutions, etc. ARM TrustZone technology is a system-wide security solution for SoCs and CPUs launched by ARM (an intellectual property provider), and has been widely used on some processors using the ARM instruction set. Intel SGX (Intel Software Guard Extensions) is a set of security-related extension instructions built into sixth-generation and later Intel central processing units (CPUs). This application does not limit the TEE technology; the following embodiments of this application will use Intel SGX technology as an example for further explanation.

[0074] Taking Intel SGX technology as an example, based on this technology, specific memory regions (also known as protected memory regions) within the trusted execution environment of a trusted execution node can be set as object-private regions, also known as enclaves. The contents of these enclaves are protected and cannot be accessed by any process other than the node itself. These other processes can include, but are not limited to, processes running at higher privilege levels, such as Virtual Machine Manager (VMM) processes, Basic Input Output System (BIOS) processes, and Operating System (OS) processes. SGX provides the following characteristics: ① Confidentiality and integrity: Code and data within enclaves can resist snooping or modification by any other software, including but not limited to privileged software such as the VMM, BIOS, and OS; ② Minimized attack surface: The CPU boundary is the trust boundary of SGX. SGX only trusts data within the CPU boundary; data is encrypted as soon as it leaves the CPU. Therefore, placing the protected parts of the first application's code within an SGX enclave for execution can improve the security of the first application running on platforms that may be attacked. When the first application in the trusted execution node is running, the Intel SGX instruction set can create an enclave in a protected memory region. The part of the first application's code that needs to be protected runs in the enclave (the part of the code running in the enclave can be called the trusted part of the first application, and the rest of the code can be called the untrusted part). The untrusted part of the first application's access to the enclave is strictly restricted to the entry and exit functions defined by the developer, thereby isolating it from attacks by other code (including but not limited to privileged code VMM, BIOS, OS, etc.) to protect confidential data and code (i.e., protect the trusted part and its related data). When the trusted part in the enclave finishes running, it generates a return value (i.e., the call result) and returns it to the caller (i.e., the untrusted part of the first application).

[0075] See Figure 5 This is a schematic diagram illustrating the execution process of a first application in a trusted execution node according to an embodiment of this application; it may include the following process:

[0076] (1) The first application runs in the trusted execution node; (2) The Intel SGX instruction set can create an enclave in the protected memory region (i.e., Create Enclave); (3) The trusted part of the first application is called through the entry and exit functions defined by the developer (represented as Gate in the diagram) (i.e., Call Trusted()); (4) The trusted part of the first application runs in the trusted execution environment of the trusted execution node (i.e., Processing); (5) The trusted part of the first application finishes running and generates a return value, which is returned to the untrusted part (i.e., Return); (6) After receiving the return value, the untrusted part of the first application performs subsequent operations.

[0077] Furthermore, when the trusted execution node generates block data using the target block and the corresponding execution result, and this block data is executed by the trusted part of the first application, the untrusted part of the first application running in the trusted execution node can receive business requests initiated by the client and call the trusted part to forward the transactions carried by the business request to the trusted part. The trusted part, through its operation, packages the transactions carried by the business request into a target block in the trusted execution environment built into the trusted execution node, executes the target block in the built-in trusted execution environment, obtains the execution result, and then generates block data using the target block and the corresponding execution result, and returns the block data to the untrusted part. The untrusted part can then send the block data to the consensus nodes in the blockchain network.

[0078] In this embodiment, a trusted execution node located outside the blockchain network and equipped with a built-in trusted execution environment can be used to partially respond to business requests initiated by clients. Specifically, the trusted execution node can receive business requests from clients; package the transactions carried by the business request into a target block within the trusted execution environment; execute the target block within the trusted execution environment to obtain the execution result; generate block data using the target block and the execution result; and then send the block data to the consensus nodes in the blockchain network. After the consensus nodes in the blockchain network reach a consensus on the block data, they store the block data in the blockchain. The processes involved in responding to business requests, such as packaging transactions and executing blocks, are executed by the trusted execution node outside the blockchain network, not by the consensus nodes in the blockchain network. The consensus nodes in the blockchain network store the block data, thus enabling off-chain computation and on-chain storage capabilities. This reduces the computational pressure on the blockchain network, thereby improving its stability. Furthermore, the reduced computational pressure lowers the hardware configuration requirements for the consensus nodes in the blockchain network, thereby saving on the hardware costs of the blockchain network. Furthermore, since the processes of packaging transactions and executing blocks occur within the trusted execution environment of trusted execution nodes, this environment is a secure zone isolated from the operating system of the trusted execution nodes. This protects the program code running within it from modification by other program code, ensuring that even if the target block and execution result are generated outside the blockchain network, they remain trustworthy. In summary, this reduces the computational burden on the blockchain network, thereby improving its stability. It also lowers the hardware requirements for consensus nodes in the blockchain network, thus saving on hardware costs.

[0079] Based on the description of the above data processing method embodiments, this application provides another data processing method. See also Figure 6 This is a flowchart illustrating another data processing method provided in an embodiment of this application; it may include the following steps:

[0080] S601, the client initiates a service request to the trusted execution node.

[0081] The business request carries a transaction, and the relevant process of step S601 is similar to that of step S401, so it will not be described again here.

[0082] S602: The trusted execution node receives a business request initiated by the client, packages the transaction carried by the business request into a target block in the built-in trusted execution environment, and executes the target block in the built-in trusted execution environment to obtain the execution result.

[0083] The process in step S602 is similar to that in step S402 described above. Further optionally, after receiving a business request from a client, the trusted execution node can verify the transactions carried in the business request. If verification fails, the transaction is ignored; if verification passes, the transactions carried in the business request are packaged into a target block within the built-in trusted execution environment, and the target block is executed within the built-in trusted execution environment to obtain the execution result. Optionally, the process of the trusted execution node verifying the transactions carried in the business request can be performed within the trusted execution environment or in other areas; this embodiment does not impose any limitations. Further optionally, the trusted execution node verifies the transactions carried in the business request... During verification, the trusted execution node can verify whether the transaction has already been stored in the ledger. This is because transactions stored in the ledger should be completed transactions that do not require further processing. If the transaction does not exist in the ledger, the verification is considered successful. Based on this, the trusted execution node can also send the transaction carried by the business request to the consensus node of the blockchain network so that the consensus node can store it in the ledger. Optionally, if the transaction carried by the business request has signature information, the trusted execution node can also verify the corresponding signature information when verifying the transaction. Verification is considered successful after the signature is verified. Optionally, after receiving the execution result, the trusted execution node can send execution feedback information to the client. This execution feedback information can carry the execution result so that the object that initiated the business request through the client can know the corresponding execution result.

[0084] S603, The trusted execution node obtains verification information, which is used to verify whether at least one of the following objects is trusted: the trusted execution node, the target block, and the execution result.

[0085] In one embodiment, a target application runs in the trusted execution environment of the trusted execution node (i.e., the first application in the trusted execution node is deployed in the trusted part of the trusted execution environment). The trusted execution node packages transactions and executes blocks through the target application built into the trusted execution environment. Based on this, when verification information can be used to verify whether the trusted execution node is trustworthy, the verification information includes a first remote authentication report. At this time, the trusted execution node obtains the verification information, which may include: obtaining program attribute information of the target application in the trusted execution environment, the program attribute information being used to verify whether the corresponding target application is trustworthy; obtaining verification information of the program attribute information, the verification information being used to verify whether the program attribute information is valid; using the program attribute information and the verification information, generating a first remote authentication report, and using the first remote authentication report as the verification information; wherein, the consensus node in the blockchain network determines the validity of the program attribute information based on the verification information, and then verifies whether the target application in the trusted execution environment is trustworthy based on the program attribute information, thereby verifying whether the trusted execution node is trustworthy.

[0086] In one embodiment, the aforementioned program attribute information may include at least one of the following: an application metric value of the target application in the trusted execution environment, and application signature information of the target application in the trusted execution environment; wherein, the application metric value is used to uniquely identify the target application in the trusted execution environment, and the application signature information is used to indicate the developer of the target application in the trusted execution environment; the aforementioned verification information may include: the block hash value of the reference block; the reference block refers to: the last block generated by the trusted execution node before generating the target block; wherein, the consensus node in the blockchain network determines whether the program attribute information is valid by comparing whether the block hash value of the reference block is consistent with the block hash value of the last block on the blockchain.

[0087] In the trusted execution environment of a trusted execution node, the application metric of the target application is calculated in real time by the CPU based on the running target application. This metric is tamper-proof and uniquely identifies the target application within the trusted execution environment, similar to a software checksum. Consensus nodes in the blockchain network verify the application metric of the target application within the trusted execution environment to determine if the target application has been tampered with, and further, whether the target application and the trusted execution node are trustworthy. If the trusted execution node is deemed trustworthy, the received target block and execution result are considered trustworthy. The application signature information of the target application within the trusted execution environment can indicate the developer of the target application. Consensus nodes in the blockchain network verify this signature to determine if the developer of the target application running in the trusted execution environment is the genuine developer, preventing third parties who are not the genuine developer from sending erroneous information or obtaining information during interactions. The reference block refers to the last block generated by the trusted execution node before generating the target block, i.e., the block preceding the target block. The verification information required to generate the first remote authentication report uses the block hash value of the reference block, which indicates that the first remote authentication report is the corresponding report generated during the generation of the target block. Consensus nodes in the blockchain network can determine whether the first remote authentication report is the corresponding report generated during the generation of the target block by comparing the block hash value of the last block on the blockchain in their local space with the block hash value in the first remote authentication report. This allows them to determine whether the program attribute information in the first remote authentication report is valid, avoiding the need for the trusted execution node to send reports generated during the historical block generation process for verification. It ensures the real-time nature of the trustworthiness verification of the trusted execution node and guarantees that the target application in the trusted execution node is trustworthy when generating the target block and executing the result.

[0088] In one embodiment, when the verification information can be used to verify whether the target block and the execution result are trustworthy, the verification information may include the signature information of the target block and the signature information of the execution result. In this case, the trusted execution node obtains the verification information by: signing the target block with a first key to obtain the signature information of the target block; and signing the execution result with a second key to obtain the signature information of the execution result. Both the signature information of the target block and the signature information of the execution result are used as verification information, so that the consensus nodes in the blockchain network can verify whether the target block is trustworthy based on the signature information of the target block, and verify whether the execution result is trustworthy based on the signature information of the execution result. Optionally, when the trusted execution node signs the target block and the execution result, it can be based on a symmetric key mechanism and an asymmetric key mechanism. When based on a symmetric key mechanism, the first key and the second key can be keys negotiated in advance with the consensus nodes in the blockchain network, and the first key and the second key can be the same or different. When based on an asymmetric key mechanism, the first key and the second key can be the private key of the trusted execution node, and the first key and the second key can be the same or different. The encryption / decryption speed is fast when using a symmetric key mechanism, while the encryption / decryption speed is more flexible when using an asymmetric key mechanism. The choice between a symmetric key mechanism and an asymmetric key mechanism can be made according to specific needs, and this application embodiment does not impose any restrictions.

[0089] S604, the trusted execution node generates block data using the target block, execution result, and verification information.

[0090] The process of step S604 is similar to that of step S403, and will not be described again here; furthermore, the consensus nodes in the blockchain network verify the trustworthiness of the corresponding object based on the verification information, and then perform consensus processing on the target block and execution result in the block data.

[0091] S605, the trusted execution node sends block data to the consensus nodes in the blockchain network.

[0092] The process of step S605 is similar to that of step S404 above, and will not be described again here.

[0093] S606, consensus nodes in a blockchain network receive block data generated by trusted execution nodes.

[0094] The block data includes the target block and the execution result. The target block is obtained by packaging the transaction carried by the transaction request initiated by the client in the trusted execution environment within the trusted execution node. The execution result is obtained by executing the target block in the trusted execution environment within the trusted execution node. The trusted execution node refers to a device located outside the blockchain network and with a built-in trusted execution environment. The trusted execution environment within the trusted execution node is a secure area isolated from the operating system of the trusted execution node.

[0095] S607, consensus nodes in the blockchain network perform trusted verification of the corresponding object based on the verification information in the block data, and obtain the object verification result.

[0096] In one embodiment, since the trusted execution node packages transactions and executes blocks through a target application within a built-in trusted execution environment; when the verification information includes a first remote authentication report, since the first remote authentication report is generated using the program attribute information and verification information of the target application used by the trusted execution node (i.e., the target application running in the trusted execution environment of the trusted execution node); based on this, the consensus nodes in the blockchain network perform trusted verification on the corresponding object according to the verification information in the block data to obtain the object verification result, which may include: obtaining the first remote authentication report from the verification information in the block data, and verifying the validity of the program attribute information in the first remote authentication report according to the verification information in the first remote authentication report to obtain a verification result; if the verification result indicates that the program attribute information in the first remote authentication report is valid, then trusted verification is performed on the target application used by the trusted execution node according to the program attribute information in the first remote authentication report; if the target application used by the trusted execution node passes the trusted verification, then the trusted execution node is determined to be trusted; if the target application used by the trusted execution node fails the trusted verification, then the trusted execution node is determined to be untrustworthy.

[0097] Specifically, since the verification information used in the first remote authentication report includes the block hash value of the reference block, where the reference block refers to the last block generated by the trusted execution node before generating the target block, the consensus nodes in the blockchain network specifically verify the validity of the program attribute information in the first remote authentication report based on the verification information in the first remote authentication report, and obtain the verification result. This can include: obtaining the block hash value of the last block on the blockchain in the local space, and comparing the obtained block hash value with the block hash value in the first remote authentication report; if the two block hash values ​​are consistent, a verification result indicating that the program attribute information in the first remote authentication report is valid is generated; if the two block hash values ​​are inconsistent, a verification result indicating that the program attribute information in the first remote authentication report is invalid is generated. In other words, the verification information required by the trusted execution node to generate the first remote authentication report uses the block hash value of the reference block. This indicates that the first remote authentication report is the report generated during the generation of the target block. The consensus node in the blockchain network compares the block hash value of the last block on the blockchain in its local space with the block hash value in the first remote authentication report. If the two block hash values ​​are consistent, it can be determined that the first remote authentication report is the report corresponding to the target block currently received by the consensus node in the blockchain network. Therefore, it can be determined that the received first remote authentication report is not an expired report, and thus the received first remote authentication report is valid. This allows the generation of a verification result to indicate the validity of the program attribute information in the first remote authentication report.

[0098] Furthermore, the target application used by the trusted execution node must be audited by the auditing platform before being deployed to the trusted execution environment within the trusted execution node; and after passing the auditing platform's audit, the corresponding target application is recognized as a trusted target application. Based on this, the consensus nodes in the blockchain network perform trusted verification on the target application used by the trusted execution node according to the program attribute information in the first remote authentication report. This may include: obtaining a third remote authentication report about the trusted execution node from the auditing platform, the third remote authentication report including: program attribute information of the target application that is allowed to be deployed in the trusted execution environment of the trusted execution node and has passed the audit; comparing the consistency of the program attribute information in the third remote authentication report with the program attribute information in the first remote authentication report; if the two program attribute information are consistent, it is determined that the target application used by the trusted execution node has passed trusted verification; if the two program attribute information are inconsistent, it is determined that the target application used by the trusted execution node has not passed trusted verification. Specifically, by comparing the program attribute information in the first and third remote authentication reports, if the application metrics included in the two reports are the same, it proves that the target application running in the trusted execution environment of the trusted execution node is the same as the target application that has been allowed to be deployed in the trusted execution environment of the trusted execution node and has passed the audit, i.e., it has not been tampered with. If the application signature information in the two reports is the same, it proves that the developer of the target application running in the trusted execution environment of the trusted execution node is the same as the developer of the target application that has been allowed to be deployed in the trusted execution environment of the trusted execution node and has passed the audit. If the developers indicated by the application metrics and application signature information are the same, it is determined that the target application used by the trusted execution node has not passed the trusted verification. Further optionally, the consensus node in the blockchain network can directly obtain the third remote authentication report about the trusted execution node from the audit platform, or it can store the third remote authentication report about the trusted execution node obtained in advance from the audit platform in local space, and retrieve it from local space when it is needed, which can speed up the retrieval speed of the third remote authentication report. The audit process of the target application will be described in subsequent embodiments and will not be repeated here.

[0099] In one embodiment, when the verification information includes the signature information of the target block and the signature information of the execution result, the consensus nodes in the blockchain network perform trusted verification on the corresponding object based on the verification information in the block data. When the object verification result is obtained, the signature information can be verified based on the corresponding key to verify the trustworthiness of the target block and the execution result. When the signature information of the target block is implemented based on a symmetric key mechanism, a first key can be used for signature verification; when the signature information of the target block is implemented based on an asymmetric key mechanism, the public key corresponding to the first key can be used for signature verification. When the signature information of the execution result is implemented based on a symmetric key mechanism, a second key can be used for signature verification; when the signature information of the execution result is implemented based on an asymmetric key mechanism, the public key corresponding to the second key can be used for signature verification. The signing and verification process of the target block and the execution result can be implemented using existing technologies, and this application embodiment does not impose any limitations.

[0100] S608 If the object verification result indicates that the corresponding object is trustworthy, the consensus nodes in the blockchain network perform consensus processing on the target block and execution result in the block data, and after reaching a consensus on the block data, store the block data in the blockchain.

[0101] The process of step S608 is similar to that of step S405, and will not be described again here.

[0102] In one embodiment, if the trusted execution node uses Intel SGX technology for its TEE, the following section describes the trustworthiness verification process for the trusted execution node based on this technology (this process can also be referred to as the remote authentication process for the trusted execution node). When the trusted execution node generates the first remote authentication report, the target application in the trusted execution environment of the trusted execution node (i.e., the trusted part of the first application of the trusted execution node, also known as the application enclave) can obtain the program attribute information of the target application in the trusted execution environment, as well as the verification information of the program attribute information, and use the program attribute information and verification information to generate a local authentication report (REPORT). The target application (application enclave) transmits the local authentication report (REPORT) to the quotting enclave (QE) in the trusted execution environment of the trusted execution node. The QE can obtain the key (REPORTKEY) of the local authentication report and, based on the REPORT,... The KEY verifies the local authentication report to determine whether the target application is running on the same platform as QE. If it is determined that the target application is running on the same platform as QE, the local authentication report can be signed using the private key unique to this platform to obtain the first remote authentication report (which can be called a Quote). When the target application generates a local authentication report (REPORT) using program attribute information and verification information, it can do so by calling the SGX's EREPORT instruction. QE is an architecture enclave developed and signed by Intel, which can be used to perform local verification of the target application, i.e., to verify whether the target application's running platform and the QE's running platform are the same platform (i.e., whether they are trusted execution environments within the same SGX processor). If QE determines that the target application is running on the same platform as QE, it can use its platform-specific private key to sign the local authentication report, obtaining a first remote authentication report. The private key used to sign the local authentication report is the private key corresponding to the Intel-certified SGX processor. Based on this, the first remote authentication report can be further used to determine whether the platform that generated the first remote authentication report is a certified SGX platform. Since the first remote authentication report is generated when the target application and QE belong to the same platform, the target application's running environment can also be determined based on the first remote authentication report, i.e., whether the target application's running environment is a trusted execution environment within a certified SGX processor.Upon receiving the first remote authentication report, the consensus node in the blockchain network can, in addition to verifying the trustworthiness of the target application by comparing it with the third remote authentication report, also invoke Intel Attestation Service (IAS) to verify whether the target application's runtime environment is a trusted execution environment of the certified SGX processor, i.e., whether the target application's runtime environment is trustworthy. Furthermore, if the target application and its runtime environment are both verified to be trustworthy, the trusted execution node can be determined to be trustworthy. This process relies on the remote authentication capabilities provided by Intel SGX technology. These capabilities can be used to authenticate whether an application's enclave runtime environment possesses SGX hardware protection capabilities and whether the protected code and data of the application have been tampered with. After successful authentication, the enclave is considered trustworthy. At this point, the program or device initiating the remote authentication request can provide its keys, identity information, and other sensitive data to the enclave when it needs to use its services.

[0103] In this embodiment, a trusted execution node located outside the blockchain network and equipped with a built-in trusted execution environment can be used to implement a partial response process to business requests initiated by clients. Specifically, the trusted execution node can receive business requests initiated by clients; package the transactions carried by the business request into a target block within the trusted execution environment; execute the target block within the trusted execution environment to obtain the execution result; generate block data using the target block, the execution result, and verification information that can be used to verify the trustworthiness of the trusted execution node, the target block, and the execution result; and then send the block data to the consensus nodes in the blockchain network. This allows the consensus nodes in the blockchain network to perform trusted verification of the corresponding objects based on the verification information in the block data. If the corresponding objects are determined to be trustworthy, consensus processing is performed on the target block and the execution result in the block data. After reaching a consensus on the block data, the block data is stored in the blockchain. The processes involved in responding to business requests, such as transaction packaging and block execution, are performed by trusted execution nodes outside the blockchain network, not by consensus nodes within the blockchain network. The consensus nodes in the blockchain network store the block data, enabling off-chain computation and on-chain storage capabilities. This reduces the computational burden on the blockchain network, thereby improving its stability. Furthermore, the reduced computational burden lowers the hardware requirements for consensus nodes, saving on hardware costs. This also allows more low-configuration devices to connect to the blockchain, enhancing its decentralization. Since transaction packaging and block execution occur within the trusted execution node's trusted execution environment—a secure area isolated from the node's operating system—the program code running within it is protected from modification by other program code. This ensures that even if the target block and execution result are generated outside the blockchain network, they remain trustworthy.

[0104] Furthermore, based on the verification information, it is possible to verify whether one or more of the trusted execution node, target block, and execution result are trustworthy. When verifying the trustworthiness of the trusted execution node, the trusted execution node can generate a first remote authentication based on the block hash value of the reference block. The consensus node in the blockchain network can compare the block hash value of the last block on the blockchain in its local space with the block hash value in the first remote authentication report. If the two block hash values ​​are consistent, it can be determined that the first remote authentication report is the report corresponding to the target block currently received by the consensus node in the blockchain network. Therefore, it can be determined that the received first remote authentication report is not an expired report, which can prevent the trusted execution node from using an expired remote authentication report to bypass the trustworthiness verification of the trusted execution node. It can identify whether the block data sent by the trusted execution node is the expired block data generated in the process of generating the expired remote authentication report, which can further reduce the situation of uploading erroneous block data to the chain.

[0105] In one embodiment, when a trusted execution node sends block data to consensus nodes in a blockchain network, it can send block data directly to each consensus node in the blockchain network; alternatively, it can send block data to some consensus nodes in the blockchain, so that the consensus nodes receiving the block data can broadcast the block data to other consensus nodes. In this case, sending block data from a trusted execution node to consensus nodes in the blockchain network can include: determining a target consensus node from among the multiple consensus nodes in the blockchain network, where the target consensus node is a consensus node with verification capabilities; sending block data to the target consensus node, so that after the target consensus node verifies the trustworthiness of the corresponding object based on the verification information in the block data, it broadcasts the block data to the remaining consensus nodes, allowing the remaining consensus nodes to perform consensus processing on the target block and execution result in the block data. In an optional embodiment, the trusted execution node can store node identifiers of consensus nodes that have established communication connections with the blockchain network. The trusted execution node can select one or more node identifiers from the stored node identifiers to use the consensus node indicated by the node identifier as the target consensus node. For ease of explanation, this embodiment uses one target consensus node as an example. See Figure 7a This is a flowchart illustrating another data processing method provided in an embodiment of this application; it may include the following steps:

[0106] S701, The client initiates a business request to the trusted execution node. S702, The trusted execution node receives the business request from the client, packages the transaction carried by the business request into a target block within its built-in trusted execution environment, and executes the target block within the built-in trusted execution environment to obtain the execution result. S703, The trusted execution node obtains verification information, which is used to verify whether at least one of the following objects is trustworthy: the trusted execution node, the target block, and the execution result. S704, The trusted execution node generates block data using the target block, the execution result, and the verification information. S705, The trusted execution node sends the block data to the target consensus node in the blockchain network. S706, The target consensus node in the blockchain network receives the block data generated by the trusted execution node. S707, The target consensus node in the blockchain network performs trust verification on the corresponding object based on the verification information in the block data to obtain the object verification result. S708, If the corresponding object verification result indicates that the corresponding object is trustworthy, the target consensus node in the blockchain network broadcasts the block data to the remaining consensus nodes and performs consensus processing on the target block and the execution result in the block data. S709, the remaining consensus nodes in the blockchain network receive the block data broadcast by the target consensus node; S710, the remaining consensus nodes in the blockchain network perform trusted verification on the corresponding object based on the verification information in the block data, and obtain the object verification result; S711, if the corresponding object verification result indicates that the corresponding object is trusted, the remaining consensus nodes in the blockchain network perform consensus processing on the target block and execution result in the block data; S712, after reaching a consensus on the block data, the consensus nodes in the blockchain network store the block data in the blockchain.

[0107] See Figure 7bThis diagram illustrates a data processing system for handling business requests, as provided in this application embodiment. A client can respond to a business request triggering operation performed by an object within the client, and initiate a business request to a trusted execution node based on this triggering operation. Optionally, the business request triggering operation performed by the object within the client may include: a contract invocation operation, during which the object can input corresponding data (corresponding to "invoking the contract with data as a parameter" in the diagram); or, a business contract development or deployment operation (corresponding to "developing and deploying the business contract" in the diagram), which can be executed by the developer of the data processing system. Business requests initiated by the client may include transaction requests and query requests. The trusted execution node can perform processes such as packaging transactions, executing blocks, and propagating block data (including propagating the target block, execution results, and verification information) based on its built-in trusted execution environment. Specifically, the trusted execution node can send block data to the target consensus node in the blockchain network. After receiving the block data, the target consensus node can perform processes such as object verification (including verifying one or more of the first remote authentication report to verify the trusted execution node, verifying the signature information of the target block, and the signature information of the execution result), broadcasting block data, consensus processing, and saving the ledger. The processing procedures of each device in the data processing system Figure 7a The process has been described in detail and will not be repeated here. Optionally, the target consensus node can store the block data in the ledger only after a majority of consensus nodes in the blockchain network have received it. This can prevent inconsistencies from occurring when a trusted execution node fails and only sends the block data to a few consensus nodes, leading to data discrepancies among the consensus nodes after the trusted nodes recover.

[0108] In one embodiment, a client initiates a service request to a trusted execution node after confirming the node's trustworthiness. Since the target application runs within the trusted execution environment, the trusted execution node packages transactions and executes blocks using the target application built into the trusted execution environment. Based on this, see [link to relevant documentation]. Figure 8 This is a schematic diagram illustrating a client verifying the trustworthiness of a trusted execution node, provided in an embodiment of this application. The verification process may include the following steps:

[0109] S801, the client initiates a remote authentication request to the trusted execution node. The remote authentication request is used to verify whether the target application in the trusted execution environment is trustworthy, and the remote authentication request carries a random number. S802, the trusted execution node receives the remote authentication request initiated by the client. S803, in response to the remote authentication request, the trusted execution node obtains the program attribute information of the target application in the trusted execution environment. The program attribute information is used to verify whether the corresponding target application is trustworthy. S804, a second remote authentication report is generated using the program attribute information, and the random number carried in the remote authentication request is added to the second remote authentication report to indicate that the second remote authentication report is a valid remote authentication report. S805, the second remote authentication report is returned to the client, so that after determining that the received second remote authentication report is valid, the client verifies whether the corresponding target application is trustworthy based on the program attribute information in the second remote authentication report, thereby verifying whether the trusted execution node is trustworthy. After determining that the trusted execution node is trustworthy, the client initiates a transaction request to the trusted execution node. S806, the client receives the second remote authentication report returned by the trusted execution node and determines whether the received second remote authentication report is valid based on the random number in the received second remote authentication report. S807: After confirming the validity of the received second remote authentication report, verify whether the corresponding target application is trustworthy based on the program attribute information in the second remote authentication report. S808: If the corresponding target application is determined to be trustworthy, then the trusted execution node is determined to be trustworthy; subsequently, a transaction request can be initiated to the trusted execution node.

[0110] The process of the trusted execution node generating the second remote authentication report is similar to that of generating the first remote authentication report. However, the first remote authentication report is generated based on the block hash value of the reference block, while the second remote authentication report is generated based on the random number carried in the remote authentication request. This random number serves the same purpose as the block hash value of the reference block: ensuring that the trusted execution node cannot use an outdated remote authentication report to bypass the trustworthiness verification of the trusted execution node (i.e., bypass remote authentication), thus guaranteeing the real-time nature of remote authentication and further verifying whether the trusted execution node is currently trustworthy. The process of the client verifying the trustworthiness of the trusted execution node is similar to the process of the consensus node in the blockchain network verifying the trustworthiness of the trusted execution node. In step S806, the client can compare the random number carried in the initiated business request with the random number in the received second remote authentication report. If they match, the received second remote authentication report is deemed valid. In step S807, the client can also obtain a third remote authentication report about the trusted execution node from the auditing platform; compare the program attribute information in the third remote authentication report with the program attribute information in the second remote authentication report; if the two program attribute information are consistent, the target application used by the trusted execution node is determined to be trustworthy; if the two program attribute information are inconsistent, the target application used by the trusted execution node is determined to be untrustworthy. Optionally, the client can periodically initiate remote authentication requests to the trusted execution node to remotely verify the trustworthiness of the trusted execution node, ensuring that the client establishes a communication connection with a trusted execution node, preventing transactions from being sent to an unreliable environment through business requests, causing erroneous responses to business requests (e.g., data related to the transaction being deleted or unable to be uploaded to the blockchain), while ensuring the security of the trusted execution node's environment and the trustworthiness of the target blocks and execution results generated by its response to business requests. Based on the process of a client actively initiating remote authentication to a trusted execution node, it can be seen that consensus nodes in the blockchain network (such as the target consensus node) can also actively verify the trustworthiness of a trusted execution node by initiating a remote authentication request. This process is similar to the process of a client actively initiating remote authentication to a trusted execution node, and will not be elaborated here.

[0111] In one embodiment, if the trusted execution node uses Intel SGX technology, see [link to relevant documentation]. Figure 9This diagram illustrates another client-side verification of the trustworthiness of a trusted execution node, provided in an embodiment of this application. The client acts as a service provider (Challenger). ① The client initiates a remote authentication request to the trusted execution node, carrying a random number generated by the client. The trusted execution node is then used as a UserPlatform. ② The untrusted portion (Application) of the first application of the trusted execution node receives the remote authentication request initiated by the client and passes the data carried in the request (including the random number) to the trusted portion (Application Enclave, i.e., the target application) of the first application of the trusted execution node. ③ The target application (the trusted portion of the first application of the trusted execution node) within the trusted execution environment can obtain the program attribute information of the target application in the trusted execution environment and generate a local authentication report (REPORT) using the program attribute information and the received random number. This process can be implemented by calling the SGX EREPORT instruction with the random number as a parameter. Furthermore, the target application can return the local authentication report (REPORT) to the untrusted portion, allowing the untrusted portion to pass the local authentication report to the architectural enclave within the trusted execution environment of the trusted execution node. ④ The untrusted part transmits the local authentication report to the QE (Qualified Enclave) architecture within the trusted execution environment of the trusted execution node. ⑤ The QE obtains the key (REPORT KEY) of the local authentication report and verifies it based on this REPORT KEY to determine if the target application runs on the same platform as the QE. If it determines that the target application runs on the same platform as the QE, it can sign the local authentication report using its platform-specific private key to obtain a second remote authentication report (which can be called a Quote), and return the second remote authentication report to the untrusted part so that the untrusted part can send it to the client. ⑥ The untrusted part can return the second remote authentication report to the client. ⑦ The client can verify whether the trusted execution node is trusted based on the received second remote authentication report; optionally, the client can also call the Intel Attestation Service (IAS) to verify the second remote authentication report to verify whether the target application's runtime environment is a trusted execution environment of the certified SGX processor, i.e., whether the target application's runtime environment is trusted. Further, if the target application and its runtime environment are verified to be trusted, the trusted execution node can be determined to be trusted. This process is similar to the process described above where consensus nodes in a blockchain network, based on Intel SGX technology, remotely authenticate trusted execution nodes using the first remote authentication report.

[0112] Optionally, the process of verifying the trustworthiness of the trusted execution node by the client may further include the implementation of the DH communication key negotiation algorithm, whereby the negotiated key is used to ensure secure communication between the client and the trusted execution node; wherein, in Figure 9 In step ①, the client can also generate a DH communication key pair (denoted by A). The remote authentication request initiated by the client to the trusted execution node also carries the public key of A. In step ③, the target application in the trusted execution environment of the trusted execution node can also generate a DH communication key pair (denoted by B). The public key of B can be used as a parameter when generating a local authentication report, so that the generated local authentication report carries the public key of B, and thus the generated second remote authentication report carries the public key of B. Based on this, after receiving the second remote authentication report, the client can obtain the public key of B, and the client and the trusted execution node can combine their... The private key possessed by the client and the public key of the other party can be used to calculate the same symmetric communication key. This symmetric communication key can be used for subsequent encrypted communication between the client and the trusted execution node. Furthermore, the communication key negotiation process ensures that the trusted execution environment participating in remote authentication is the same as the actual operating environment of the target application. Since other environments of the trusted execution node do not participate in key negotiation, they cannot calculate the communication key and cannot decrypt the communication content sent by the client. Optionally, the communication key negotiation process can be performed when the client first initiates a remote authentication request to the trusted execution node, or it can be performed every time; this application embodiment does not impose any restrictions. Similarly, a consensus node in the blockchain network (e.g., the target consensus node) can actively initiate remote authentication to the trusted execution node to achieve the negotiation process of the communication key between the target application and the trusted execution node. This process is similar to the key negotiation process between the client and the trusted execution node, and will not be described in detail here.

[0113] In one embodiment, since the target application is program code within the first application, the auditing platform can audit the target application by auditing the first application; when auditing the first application, a remote authentication report obtained by running the first application in a trusted trusted execution environment can be used as a third remote authentication report. For example, see... Figure 10This is a schematic diagram illustrating the review process of a target application provided in this embodiment of the application. A blockchain application developer can upload a first application (which is a blockchain application) to the review platform, select a review body, describe the application functions, and initiate a review. The selected review body can accept review tasks through the review platform. Optionally, the selected review body can conduct the review based on expert rules or other methods; this embodiment of the application does not impose such limitations. After the selected review body completes the review of the first application, if the review passes, it can request the compilation of the first application from a public trusted execution environment in the cloud (i.e., a trusted execution environment) and request the return of a remote authentication report (the returned remote authentication report...). The process authentication report is the aforementioned third remote authentication report; the cloud-based public trusted execution environment can return the compiled first application and the corresponding third remote authentication report to the auditing platform; the auditing platform can collect the comprehensive opinions of various auditing agencies on the trusted application, and if it passes, it will issue a remote authentication report pass information so that other terminals can obtain the third remote authentication report from the auditing platform; furthermore, blockchain program developers can download the compiled first application from the auditing platform to deploy the compiled first application on the trusted execution node; it can be understood that the first application running on the trusted execution node in this application embodiment should all be the compiled first application. Figure 10 The audit process shown is only an exemplary audit process. Specific rules and operations for the audit can be set according to specific needs. This application embodiment does not impose any limitations. Its purpose is to obtain a trustworthy remote authentication report corresponding to the trusted part of the first application.

[0114] In this embodiment, the client can periodically initiate remote authentication requests to the trusted execution node to remotely verify the trustworthiness of the trusted execution node. This ensures that the client establishes a communication connection with a trusted execution node, preventing transactions from being sent to an unreliable environment through business requests, which could lead to erroneous responses to business requests (such as data related to the transaction being deleted or unable to be uploaded to the blockchain). At the same time, it can ensure the security of the environment of the trusted execution node and the trustworthiness of the target blocks and execution results generated by its response to business requests.

[0115] In one embodiment, to reduce the impact of a failed trusted execution node on the data processing system, some or all consensus nodes in the blockchain network of the data processing system can be configured with a trusted execution environment. This environment supports the consensus nodes in implementing the functions of a trusted execution node, allowing them to function as backup nodes in the event of a trusted execution node failure. This reduces the likelihood of the data processing system crashing due to a trusted execution node failure. Since any consensus node in the blockchain network of the data processing system can be configured with a trusted execution environment to act as a backup node, this embodiment uses any consensus node in the blockchain network as an example (e.g., the target consensus node) to illustrate how to handle a trusted execution node failure. This particular consensus node has a built-in trusted execution environment and, based on this built-in environment, is qualified to act as a backup node for a trusted execution node. See also... Figure 11 This is a schematic diagram illustrating how a consensus node can respond to a trusted execution node failure, as provided in an embodiment of this application. Any consensus node in the blockchain network can execute the following process:

[0116] S1101, After determining that the trusted execution node has failed, collect heartbeat information from other consensus nodes in the blockchain network; any heartbeat information can be used to indicate the block height of the blockchain in the corresponding consensus node. S1102, Based on the collected heartbeat information and the block height of the blockchain in the corresponding consensus node, detect block synchronization needs; wherein, if the block height corresponding to the corresponding consensus node is lower than the block heights corresponding to other consensus nodes, the corresponding consensus node has a block synchronization need; otherwise, the corresponding consensus node does not have a block synchronization need. S1103, If a block synchronization need is detected, perform block synchronization processing between the corresponding consensus node and other consensus nodes. S1104, After completing the block synchronization processing, switch to a backup node of the trusted execution node and provide transaction packaging and block execution services based on the built-in trusted execution environment. S1105, If no block synchronization need is detected, switch to a backup node of the trusted execution node and provide transaction packaging and block execution services based on the built-in trusted execution environment.

[0117] Here, heartbeat information refers to the information received from a consensus node. Block height in the blockchain indicates the number of blocks in the corresponding blockchain. When the block height of any consensus node is lower than that of other consensus nodes (meaning there are consensus nodes in the blockchain network with higher block heights), it is considered that the processing progress of the received block data by this consensus node is slower than that of other consensus nodes in the blockchain network. Therefore, block synchronization is required. Only after complete block synchronization can the node switch to become a backup node for the trusted execution node, providing the same functionality as the trusted execution node in the data processing system. Optionally, when any consensus node and the trusted execution node can communicate, the consensus node can also collect the heartbeat information of the trusted execution node. The heartbeat information of the trusted execution node can be used to indicate the block data already processed by the trusted execution node, facilitating synchronization between the block data of the consensus node and the trusted execution node.

[0118] Furthermore, after any consensus node switches to become a backup node for the trusted execution node, it can receive new business requests initiated by clients and respond to these new requests. See [link to relevant documentation]. Figure 12 This is a schematic diagram illustrating how a consensus node responds to a service request after switching to a standby node, as provided in an embodiment of this application. The process may include the following steps:

[0119] S1201: Receive a new business request initiated by the client, the new business request carrying a transaction. S1202: Package the transaction carried by the new business request into a new block in the built-in trusted execution environment, and execute the new block in the built-in trusted execution environment to obtain the corresponding execution result. S1203: Generate new block data using the new block and the corresponding execution result. S1204: Broadcast the new block data to other consensus nodes in the blockchain network, so that other consensus nodes reach a consensus on the new block data, and then store the new block data in the corresponding blockchain. The relevant processes of steps S1201 to S1204 are as described above. Figure 4 , Figure 6 as well as Figure 7a The relevant processes in the illustrated embodiments are similar and will not be described in detail here.

[0120] In one embodiment, before executing step S1101, any consensus node may detect whether the trusted execution node has failed. The methods for detecting whether the trusted execution node has failed may include the following examples.

[0121] See Figure 13aThis diagram illustrates a method for detecting whether a trusted execution node has failed, as provided in an embodiment of this application. Each consensus node can predict the next time the trusted execution node will send block data, based on the time intervals between blocks historically sent by the trusted execution node. If no block data is received from the trusted execution node after the predicted time, a probe request is sent to the trusted execution node, requesting it to return data. If no data is received from the trusted execution node within a preset time period, it is determined that the trusted execution node has failed. This preset time period can be set according to specific needs, and this embodiment does not impose any limitations.

[0122] See Figure 13b This diagram illustrates another method for detecting whether a trusted execution node has failed, as provided in this embodiment of the application. Any consensus node can periodically send a probe request to the trusted execution node, which requests the trusted execution node to return data. If no data is received from the trusted execution node within a preset time period after sending the probe request, it is determined that the trusted execution node has failed. The preset time period can be set according to specific needs, and this embodiment of the application does not impose any limitations. Figure 13a as well as Figure 13b The process shown can be used to detect the interruption of the communication connection between the trusted execution node and the consensus node; furthermore, after determining that the trusted execution node has failed, the consensus node can switch to become the backup node of the trusted execution node and send a prompt message to the client, which prompts the client to send new business requests to the consensus node.

[0123] See Figure 13c This diagram illustrates another method for detecting whether a trusted execution node has failed, provided by an embodiment of this application. A client can send a new service request to the trusted execution node. If no response feedback is received from the trusted execution node within a specified time after sending the new service request, the client determines that the trusted execution node has failed. The response feedback can indicate that the trusted execution node has received the request and responded. If the client determines that the trusted execution node has failed, the client sends the new service request to any consensus node. Upon receiving the new service request from the client, the consensus node determines that the trusted execution node has failed and can then switch to become a backup node for the trusted execution node to respond to the new service request. The specified time can be set according to specific needs, and this embodiment of the application does not impose any limitations. Figure 13c The process shown can be used to detect interruptions in the communication connection between the trusted execution node and the client.

[0124] In one feasible implementation, the target consensus node is described as an example. The target consensus node can be configured to function as a consensus node and as a backup node for a trusted execution node. The program code implementing its function as a backup node for a trusted execution node is deployed in the trusted execution environment of the target consensus node. The program code implementing its function as a consensus node can be deployed in the trusted execution environment of the target consensus node or in other regions. This embodiment will subsequently be described using deployment in a trusted execution environment as an example. That is, in this case, the untrusted part of the second application in the target consensus node is used to implement proxy functions, enabling data transmission and reception externally and invoking the trusted part internally. Correspondingly, in addition to being configured as a trusted execution node, the trusted execution node can also be configured to function as a consensus node. The program code implementing its function as a consensus node can be deployed in the trusted execution environment of the trusted execution node or in other regions. This embodiment will subsequently be described using deployment in a trusted execution environment as an example. That is, in this case, the untrusted part of the first application in the trusted execution node is used to implement proxy functions, enabling data transmission and reception externally and invoking the trusted part internally.

[0125] In other words, the target consensus node and the trusted execution node can be used to implement the same function. When the data processing method proposed in the embodiments of this application is executed based on the data processing system, the trusted execution node can skip the function of being a consensus node (i.e., not run the program code that implements the relevant function (which may be called the distributed ledger function)); when the target consensus node is used as a consensus node, it can skip the function of being a backup node of the trusted execution node (i.e., not run the program code that implements the relevant function (which may be called the trusted execution function)); and when the target consensus node is switched to being a backup node of the trusted execution node, it skips the function of being a consensus node (i.e., not run the program code that implements the relevant function, i.e., not run the program code that implements the distributed ledger function) and enables the function of being a backup node of the trusted execution node (i.e., run the program code that implements the relevant function, i.e., run the program code that implements the trusted execution function).

[0126] See Figure 14This diagram illustrates how a data processing system handles business requests in the event of a trusted execution node failure, as provided in this application embodiment. In the event of a trusted execution node failure (including interruption of communication between the trusted execution node and the consensus node, or interruption of communication between the trusted execution node and the client), the client can respond to a business request triggering operation executed by an object within the client, and initiate a new business request to the target consensus node based on this triggering operation. Optionally, the business request triggering operation executed by the object within the client may include: a contract invocation operation, during which the object can input corresponding data; or, a business contract development or deployment operation, which can be executed by the developer of the data processing system. Business requests initiated by the client may include transaction requests and query requests. The target consensus node, when switched to a standby node as a trusted execution node, can skip its functions as a consensus node. This means it can skip one or more processes such as object verification (including verifying the new first remote authentication report generated based on the new business request to verify the trusted execution node, verifying the signature information of the new block, and the signature information of the new execution result), broadcasting block data, consensus processing, and saving the ledger. Instead, it can enable its functions as a standby node as a trusted execution node, which means it can execute packaged transactions, execute blocks, and propagate block data (including propagating the target block, execution result, and verification information) based on the built-in trusted execution environment. Specifically, the target consensus node can broadcast block data to other consensus nodes in the blockchain network, so that other consensus nodes can process the new block data after verifying the corresponding object indicated by the verification information, and store the new block data in the corresponding blockchain after reaching a consensus on the new block data.

[0127] See Figure 15This diagram illustrates an existing blockchain system for processing business requests, as provided in this application embodiment. The blockchain system may include clients located outside the blockchain network and multiple nodes (referred to as blockchain nodes) located within the blockchain network. Objects can interact with the blockchain through clients (DApps), and transactions (business requests) can be sent to the blockchain via DApps. Typically, the lifecycle of a transaction includes: Transaction generation: Objects can input parameter data through a DApp, which packages it into a transaction and sends it to a blockchain node. Transaction broadcast: Blockchain nodes receiving the transaction can broadcast the received transaction to all blockchain nodes in the blockchain network. Transaction verification: After receiving a transaction, blockchain nodes in the blockchain network can verify the transaction (including verifying the signature information corresponding to the transaction and checking for duplicate transactions in the ledger (DB). Transaction that passes verification enters the transaction pool, while transaction that fails verification is ignored. Transaction packaging: Blockchain nodes acting as block producers retrieve transactions from the transaction pool, package them into blocks, and broadcast the blocks to all blockchain nodes in the blockchain network. Block Verification: After receiving a block, blockchain nodes in the blockchain network verify the transactions within it. If the transaction is already in the transaction pool, it means that the transaction has been verified previously, and the verification is confirmed as successful. Otherwise, it means that the transaction has not been verified, and it needs to undergo verification such as signature verification and deduplication. Consensus Reaching: Blockchain nodes in the blockchain network vote on the received blocks based on the block verification results. When a majority of nodes reach a consensus, the block is accepted. Block verification and consensus reaching constitute the block consensus process shown in the diagram. Transaction Execution: Execute the transactions in the accepted block. Ledger Storage: Store the block, transactions, and execution results in the ledger. Based on this, it can be seen that the response process for business requests initiated by clients in existing blockchain systems all need to be executed by nodes in the blockchain network, including processes such as packaging transactions and executing blocks, resulting in high computational pressure on the blockchain network. The data processing system proposed in this application takes over some of the functions of the nodes in the blockchain network by deploying trusted execution nodes with built-in trusted execution environments outside the blockchain network. That is, the processes involved in the response to business requests, such as packaging transactions and executing blocks, can be executed by trusted execution nodes outside the blockchain network, instead of by the nodes in the blockchain network, which can reduce the computational pressure on the nodes in the blockchain network. Furthermore, since the processes of packaging transactions and executing blocks are executed based on the trusted execution environment of trusted execution nodes, the obtained blocks and execution results can be guaranteed to be trustworthy.

[0128] In this embodiment, some or all consensus nodes in the blockchain network can be configured with a trusted execution environment, and program code for implementing the same functions as the trusted execution node can be deployed in the trusted execution environment, so that it can be qualified as a backup node of the trusted execution node. When the trusted execution node fails, it can switch to the backup node of the trusted execution node and perform the relevant functions of the original trusted execution node. This can reduce the impact of the trusted execution node failure on the data processing system, that is, reduce the possibility of the data processing system crashing due to the failure of the trusted execution node and increase the stability of the data processing system.

[0129] Based on the embodiments related to the above data processing methods, this application provides a data processing apparatus. See also... Figure 16 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application. The data processing device may include a receiving unit 1601, a processing unit 1602, and a sending unit 1603. Figure 16 The data processing device shown operates within a trusted execution node, which is a device located outside the blockchain network and equipped with a built-in trusted execution environment. This trusted execution environment is a secure area isolated from the operating system of the trusted execution node. The device can be used to perform the following operations:

[0130] The receiving unit 1601 is used to receive a service request initiated by a client, wherein the service request carries a transaction.

[0131] Processing unit 1602 is configured to package the transaction carried by the business request into a target block in the trusted execution environment, and execute the target block in the trusted execution environment to obtain an execution result;

[0132] The processing unit 1602 is further configured to generate block data using the target block and the execution result;

[0133] The sending unit 1603 is used to send the block data to the consensus nodes in the blockchain network, so that after the consensus nodes in the blockchain network reach a consensus on the block data, they store the block data in the blockchain.

[0134] In one embodiment, when the processing unit 1602 generates block data using the target block and the execution result, it performs the following operations:

[0135] Obtain verification information, which is used to verify whether at least one of the following objects is trustworthy: the trusted execution node, the target block, and the execution result;

[0136] Block data is generated using the target block, the execution result, and the verification information; wherein, the consensus nodes in the blockchain network perform consensus processing on the target block and the execution result in the block data after verifying the trustworthiness of the corresponding object based on the verification information.

[0137] In one embodiment, a target application runs in the trusted execution environment, and the trusted execution node packages transactions and executes blocks through the target application built into the trusted execution environment; when the processing unit 1602 obtains verification information, it performs the following operations:

[0138] Obtain the program attribute information of the target application in the trusted execution environment, and the program attribute information is used to verify whether the corresponding target application is trustworthy;

[0139] Obtain the verification information of the program attribute information, the verification information being used to verify whether the program attribute information is valid;

[0140] Using the program attribute information and the verification information, a first remote authentication report is generated, and the first remote authentication report is used as verification information;

[0141] In this blockchain network, the consensus node verifies the trustworthiness of the target application in the trusted execution environment based on the program attribute information after determining its validity according to the verification information, thereby verifying the trustworthiness of the trusted execution node.

[0142] In one embodiment, the program attribute information includes at least one of the following: an application metric value of the target application in the trusted execution environment, and application signature information of the target application in the trusted execution environment; wherein, the application metric value is used to uniquely identify the target application in the trusted execution environment, and the application signature information is used to indicate the developer of the target application in the trusted execution environment;

[0143] The verification information includes: the block hash value of the reference block; the reference block refers to: the last block generated by the trusted execution node before generating the target block; wherein, the consensus node in the blockchain network determines whether the program attribute information is valid by comparing whether the block hash value of the reference block is consistent with the block hash value of the last block on the blockchain.

[0144] In one embodiment, when the processing unit 1602 obtains verification information, it performs the following operations:

[0145] The target block is signed using a first key to obtain the signature information of the target block; and the execution result is signed using a second key to obtain the signature information of the execution result.

[0146] Both the signature information of the target block and the signature information of the execution result are used as verification information, so that the consensus nodes in the blockchain network can verify whether the target block is trustworthy based on the signature information of the target block, and verify whether the execution result is trustworthy based on the signature information of the execution result.

[0147] In one embodiment, the blockchain network includes multiple consensus nodes; when the sending unit 1603 sends the block data to the consensus nodes in the blockchain network, it performs the following operations:

[0148] The target consensus node is determined from the plurality of consensus nodes included in the blockchain network. The target consensus node refers to a consensus node with verification capabilities.

[0149] The block data is sent to the target consensus node so that after the target consensus node verifies the trustworthiness of the corresponding object based on the verification information in the block data, it broadcasts the block data to the other consensus nodes, so that the other consensus nodes can perform consensus processing on the target block and execution result in the block data.

[0150] In one embodiment, the trusted execution environment runs a target application, and the trusted execution node packages transactions and executes blocks through the target application built into the trusted execution environment;

[0151] The receiving unit 1601 is further configured to receive a remote authentication request initiated by the client, the remote authentication request being used to request verification of whether the target application in the trusted execution environment is trustworthy, and the remote authentication request carrying a random number.

[0152] The processing unit 1602 is further configured to, in response to the remote authentication request, obtain program attribute information of the target application in the trusted execution environment, wherein the program attribute information is used to verify whether the corresponding target application is trustworthy;

[0153] The processing unit 1602 is further configured to generate a second remote authentication report using the program attribute information, and add the random number carried by the remote authentication request to the second remote authentication report, so as to indicate that the second remote authentication report is a valid remote authentication report through the random number;

[0154] The sending unit 1603 is further configured to return the second remote authentication report to the client, so that after the client determines that the received second remote authentication report is valid, it verifies whether the corresponding target application is trustworthy based on the program attribute information in the second remote authentication report, thereby verifying whether the trusted execution node is trustworthy, and after determining that the trusted execution node is trustworthy, it initiates the transaction request to the trusted execution node.

[0155] According to one embodiment of this application, Figure 4 as well as Figure 6 The data processing method shown can involve various steps that are... Figure 16 This is performed by each unit in the data processing apparatus shown. For example, Figure 4 The step S402 shown can be performed by Figure 16 The receiving unit 1601 and processing unit 1602 in the data processing device shown work together to perform their functions. Figure 4 The step S403 shown can be performed by Figure 16 The processing unit 1602 in the data processing device shown executes, Figure 4 The step S404 shown can be performed by Figure 16 The transmitting unit 1603 in the data processing device shown performs this operation. For example, Figure 6 The step S602 shown can be performed by Figure 16 The receiving unit 1601 and processing unit 1602 in the data processing device shown work together to perform their functions. Figure 6 Steps S603 to S604 shown can be derived from... Figure 16 The processing unit 1602 in the data processing device shown executes, Figure 6 The step S605 shown can be performed by Figure 16 The sending unit 1603 in the data processing device shown is executed.

[0156] According to another embodiment of this application, Figure 16 The data processing apparatus shown can be constructed by combining each unit individually or entirely into one or more other units, or one or more of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can also be implemented by multiple units, or the function of multiple units can be implemented by one unit. For example, the functions implemented by the above units can be implemented by one processing unit. In other embodiments of this application, the data processing apparatus based on logical function division may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0157] According to another embodiment of this application, the following can be achieved by running on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM), a device capable of performing operations such as... Figure 4 as well as Figure 6 The computer program (including program code) for each step involved in the corresponding method shown, to construct such... Figure 16 The data processing apparatus shown herein, and the data processing method for implementing the embodiments of this application, are described. The computer program may be recorded on, for example, a computer-readable storage medium, loaded onto the aforementioned computing device via the computer-readable storage medium, and run therein.

[0158] In this embodiment, a trusted execution node located outside the blockchain network and equipped with a built-in trusted execution environment can be used to partially respond to business requests initiated by clients. Specifically, the trusted execution node can receive business requests from clients; package the transactions carried by the business request into a target block within the trusted execution environment; execute the target block within the trusted execution environment to obtain the execution result; generate block data using the target block and the execution result; and then send the block data to the consensus nodes in the blockchain network. After the consensus nodes in the blockchain network reach a consensus on the block data, they store the block data in the blockchain. The processes involved in responding to business requests, such as packaging transactions and executing blocks, are executed by the trusted execution node outside the blockchain network, not by the consensus nodes in the blockchain network. The consensus nodes in the blockchain network store the block data, thus enabling off-chain computation and on-chain storage capabilities. This reduces the computational pressure on the blockchain network, thereby improving its stability. Furthermore, the reduced computational pressure lowers the hardware configuration requirements for the consensus nodes in the blockchain network, thereby saving on the hardware costs of the blockchain network. Furthermore, since the processes of packaging transactions and executing blocks occur within the trusted execution environment of trusted execution nodes, this environment is a secure zone isolated from the operating system of the trusted execution nodes. This protects the program code running within it from modification by other program code, ensuring that even if the target block and execution result are generated outside the blockchain network, they remain trustworthy. In summary, this reduces the computational burden on the blockchain network, thereby improving its stability. It also lowers the hardware requirements for consensus nodes in the blockchain network, thus saving on hardware costs.

[0159] Based on the aforementioned embodiments of the data processing method and the data processing apparatus, this application also provides a first electronic device, which may be the trusted execution node mentioned above. See also... Figure 17This is a schematic diagram of the structure of a first electronic device provided in an embodiment of this application. Figure 17 The first electronic device shown may include at least a processor 1701, an input interface 1702, an output interface 1703, and a computer storage medium 1704. The processor 1701, input interface 1702, output interface 1703, and computer storage medium 1704 may be connected via a bus or other means.

[0160] The computer storage medium 1704 can be stored in the memory of the first electronic device. The computer storage medium 1704 is used to store computer programs, which include program instructions. The processor 1701 is used to execute the program instructions stored in the computer storage medium 1704. The processor 1701 (or CPU (Central Processing Unit)) is the computing and control core of the first electronic device. It is suitable for implementing one or more instructions, specifically for loading and executing one or more instructions to realize the above-mentioned data processing method flow or corresponding functions.

[0161] This application embodiment also provides a computer storage medium (Memory), which is a memory device in a first electronic device used to store programs and data. It is understood that the computer storage medium here can include the built-in storage medium in the terminal, or it can include an extended storage medium supported by the terminal. The computer storage medium provides storage space, which stores the terminal's operating system. Furthermore, the storage space also stores one or more instructions suitable for loading and execution by the processor 1701. These instructions can be one or more computer programs (including program code). It should be noted that the computer storage medium here can be a high-speed random access memory (RAM), or it can be non-volatile memory, such as at least one disk storage device; optionally, it can also be at least one computer storage medium located remotely from the aforementioned processor.

[0162] In one embodiment, the processor 1701 may load and execute one or more instructions stored in the computer storage medium to achieve the above. Figure 4 as well as Figure 6 In the data processing method embodiments, the corresponding steps executed by the trusted execution node are specifically implemented such that one or more instructions in the computer storage medium are loaded and executed by the processor 1701 as follows:

[0163] Receive a business request initiated by a client, the business request carrying a transaction;

[0164] In the trusted execution environment, the transaction carried by the business request is packaged into a target block, and the target block is executed in the trusted execution environment to obtain the execution result;

[0165] Block data is generated using the target block and the execution result, and then sent to the consensus nodes in the blockchain network. After the consensus nodes in the blockchain network reach a consensus on the block data, the block data is stored in the blockchain.

[0166] In one embodiment, when the processor 1701 generates block data using the target block and the execution result, it performs the following operations:

[0167] Obtain verification information, which is used to verify whether at least one of the following objects is trustworthy: the trusted execution node, the target block, and the execution result;

[0168] Block data is generated using the target block, the execution result, and the verification information; wherein, the consensus nodes in the blockchain network perform consensus processing on the target block and the execution result in the block data after verifying the trustworthiness of the corresponding object based on the verification information.

[0169] In one embodiment, a target application runs in the trusted execution environment, and the trusted execution node packages transactions and executes blocks through the target application built into the trusted execution environment; when the processor 1701 obtains verification information, it performs the following operations:

[0170] Obtain the program attribute information of the target application in the trusted execution environment, and the program attribute information is used to verify whether the corresponding target application is trustworthy;

[0171] Obtain the verification information of the program attribute information, the verification information being used to verify whether the program attribute information is valid;

[0172] Using the program attribute information and the verification information, a first remote authentication report is generated, and the first remote authentication report is used as verification information;

[0173] In this blockchain network, the consensus node verifies the trustworthiness of the target application in the trusted execution environment based on the program attribute information after determining its validity according to the verification information, thereby verifying the trustworthiness of the trusted execution node.

[0174] In one embodiment, the program attribute information includes at least one of the following: an application metric value of the target application in the trusted execution environment, and application signature information of the target application in the trusted execution environment; wherein, the application metric value is used to uniquely identify the target application in the trusted execution environment, and the application signature information is used to indicate the developer of the target application in the trusted execution environment;

[0175] The verification information includes: the block hash value of the reference block; the reference block refers to: the last block generated by the trusted execution node before generating the target block; wherein, the consensus node in the blockchain network determines whether the program attribute information is valid by comparing whether the block hash value of the reference block is consistent with the block hash value of the last block on the blockchain.

[0176] In one embodiment, when the processor 1701 obtains verification information, it performs the following operations:

[0177] The target block is signed using a first key to obtain the signature information of the target block; and the execution result is signed using a second key to obtain the signature information of the execution result.

[0178] Both the signature information of the target block and the signature information of the execution result are used as verification information, so that the consensus nodes in the blockchain network can verify whether the target block is trustworthy based on the signature information of the target block, and verify whether the execution result is trustworthy based on the signature information of the execution result.

[0179] In one embodiment, the blockchain network includes multiple consensus nodes; when the processor 1701 sends the block data to the consensus nodes in the blockchain network, it performs the following operations:

[0180] The target consensus node is determined from the plurality of consensus nodes included in the blockchain network. The target consensus node refers to a consensus node with verification capabilities.

[0181] The block data is sent to the target consensus node so that after the target consensus node verifies the trustworthiness of the corresponding object based on the verification information in the block data, it broadcasts the block data to the other consensus nodes, so that the other consensus nodes can perform consensus processing on the target block and execution result in the block data.

[0182] In one embodiment, the trusted execution environment runs a target application, and the trusted execution node packages transactions and executes blocks through the target application built into the trusted execution environment; the processor 1701 is further configured to:

[0183] The system receives a remote authentication request initiated by the client. The remote authentication request is used to verify whether the target application in the trusted execution environment is trustworthy, and the remote authentication request carries a random number.

[0184] In response to the remote authentication request, the program attribute information of the target application in the trusted execution environment is obtained, and the program attribute information is used to verify whether the corresponding target application is trustworthy;

[0185] A second remote authentication report is generated using the program attribute information, and the random number carried in the remote authentication request is added to the second remote authentication report so that the random number indicates that the second remote authentication report is a valid remote authentication report;

[0186] The second remote authentication report is returned to the client so that after the client determines that the received second remote authentication report is valid, it verifies whether the corresponding target application is trustworthy based on the program attribute information in the second remote authentication report, thereby verifying whether the trusted execution node is trustworthy, and after determining that the trusted execution node is trustworthy, it initiates the transaction request to the trusted execution node.

[0187] This application provides a computer program product, which includes a computer program stored in a computer storage medium. A processor of a first electronic device reads the computer program from the computer storage medium and executes the computer program, causing the first electronic device to perform the above-described actions. Figure 4 as well as Figure 6 The steps shown in the method embodiment are executed by a trusted execution node. The computer-readable storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0188] Based on the embodiments related to the above data processing methods, this application provides another data processing apparatus. See also Figure 18 This is a schematic diagram of another data processing device provided in an embodiment of this application. The data processing device may include a receiving unit 1801 and a processing unit 1802. Figure 18 The data processing device shown operates on any consensus node in the blockchain network, and the device can be used to perform the following operations:

[0189] The receiving unit 1801 is used to receive block data generated by the trusted execution node. The block data includes a target block and an execution result. The target block is obtained by packaging the transaction carried by the transaction request initiated by the client in the trusted execution environment within the trusted execution node. The execution result is obtained by executing the target block in the trusted execution environment within the trusted execution node. The trusted execution node refers to a device located outside the blockchain network and having a built-in trusted execution environment. The trusted execution environment within the trusted execution node is a secure area isolated from the operating system of the trusted execution node.

[0190] The processing unit 1802 is used to perform consensus processing on the block data, and after reaching a consensus on the block data, store the block data in the blockchain.

[0191] In one embodiment, the block data further includes verification information, which is used to verify whether at least one of the following objects is trustworthy: the trusted execution node, the target block, and the execution result; when the processing unit 1802 performs consensus processing on the block data, it performs the following operations:

[0192] Based on the verification information in the block data, the corresponding object is verified to obtain the object verification result;

[0193] If the object verification result indicates that the corresponding object is trustworthy, then consensus processing is performed on the target block and execution result in the block data.

[0194] In one embodiment, the trusted execution node packages transactions and executes blocks through a target application within a built-in trusted execution environment; the verification information includes a first remote authentication report, which is generated using the program attribute information of the target application used by the trusted execution node and the verification information of the program attribute information;

[0195] When the processing unit 1802 performs trusted verification on the corresponding object based on the verification information in the block data and obtains the object verification result, it performs the following operations:

[0196] The first remote authentication report is obtained from the verification information in the block data, and the validity of the program attribute information in the first remote authentication report is verified according to the verification information in the first remote authentication report to obtain the verification result.

[0197] If the verification result indicates that the program attribute information in the first remote authentication report is valid, then the target application used by the trusted execution node is trusted and verified according to the program attribute information in the first remote authentication report.

[0198] If the target application used by the trusted execution node passes the trusted verification, the trusted execution node is determined to be trusted; if the target application used by the trusted execution node fails the trusted verification, the trusted execution node is determined to be untrustworthy.

[0199] In one embodiment, the verification information includes the block hash value of the reference block; the reference block refers to the last block generated by the trusted execution node before generating the target block.

[0200] The processing unit 1802 verifies the validity of the program attribute information in the first remote authentication report based on the verification information in the first remote authentication report. When the verification result is obtained, the processing unit 1802 performs the following operations:

[0201] Obtain the block hash value of the last block on the blockchain in the local space, and perform a consistency comparison between the obtained block hash value and the block hash value in the first remote authentication report;

[0202] If the hash values ​​of the two blocks are the same, a verification result is generated to indicate that the program attribute information in the first remote authentication report is valid; if the hash values ​​of the two blocks are different, a verification result is generated to indicate that the program attribute information in the first remote authentication report is invalid.

[0203] In one embodiment, the target application used by the trusted execution node must be reviewed by an auditing platform before being deployed to the trusted execution environment within the trusted execution node; and the corresponding target application is deemed a trusted target application after passing the review by the auditing platform.

[0204] When the processing unit 1802 performs trust verification on the target application used by the trusted execution node based on the program attribute information in the first remote authentication report, it performs the following operations:

[0205] Obtain a third remote authentication report about the trusted execution node from the auditing platform. The third remote authentication report includes: program attribute information of the target application that is allowed to be deployed in the trusted execution environment of the trusted execution node and has passed the audit.

[0206] The program attribute information in the third remote authentication report is compared with the program attribute information in the first remote authentication report for consistency.

[0207] If the attribute information of the two programs is consistent, it is determined that the target application used by the trusted execution node has passed the trusted verification; if the attribute information of the two programs is inconsistent, it is determined that the target application used by the trusted execution node has not passed the trusted verification.

[0208] In one embodiment, any consensus node has a built-in trusted execution environment, and based on the built-in trusted execution environment, any consensus node is qualified to serve as a backup node for the trusted execution node; the processing unit 1802 is further configured to:

[0209] After determining that the trusted execution node has failed, heartbeat information from other consensus nodes in the blockchain network is collected; any heartbeat information can be used to indicate the block height of the blockchain in the corresponding consensus node.

[0210] Based on the collected heartbeat information and the block height of the blockchain in any consensus node, a block synchronization requirement is detected; wherein, when the block height corresponding to any consensus node is lower than the block height corresponding to other consensus nodes, the consensus node has a block synchronization requirement.

[0211] If a block synchronization requirement is detected, block synchronization processing is performed between any of the consensus nodes and the other consensus nodes;

[0212] After completing the block synchronization process, it switches to a backup node of the trusted execution node and provides transaction packaging and block execution services based on the built-in trusted execution environment.

[0213] In one embodiment, after any consensus node is switched to become a backup node of the trusted execution node, the receiving unit 1801 is further configured to receive a new business request initiated by the client, the new business request carrying a transaction;

[0214] The processing unit 1802 is further configured to package the transaction carried by the new business request into a new block in the built-in trusted execution environment, and execute the new block in the built-in trusted execution environment to obtain the corresponding execution result;

[0215] The processing unit 1802 is further configured to generate new block data using the new block and the corresponding execution result, and broadcast the new block data to other consensus nodes in the blockchain network, so that after the other consensus nodes reach a consensus on the new block data, they store the new block data in the corresponding blockchain.

[0216] In one embodiment, the processing unit 1802 is further configured to:

[0217] Based on the time intervals of the various blocks of data historically sent by the trusted execution node, predict the time when the trusted execution node will send the next block of data.

[0218] If no block data is received from the trusted execution node after the predicted time has arrived, a probe request is sent to the trusted execution node, which is used to request the trusted execution node to return some data.

[0219] If no data is received from the trusted execution node within a preset time period, it is determined that the trusted execution node has failed.

[0220] According to one embodiment of this application, Figure 4 as well as Figure 6 The data processing method shown can involve various steps that are... Figure 18 This is performed by each unit in the data processing apparatus shown. For example, Figure 4 The step S405 shown can be performed by Figure 18 The processing unit 1802 in the data processing device shown executes this. For example, Figure 6 The step S606 shown can be performed by Figure 18 The receiving unit 1801 and the execution unit in the data processing device shown are... Figure 6 Steps S607 to S608 shown can be derived from... Figure 18 The processing unit 1802 in the data processing device shown is executed.

[0221] According to another embodiment of this application, Figure 18 The data processing apparatus shown can be constructed by combining each unit individually or entirely into one or more other units, or one or more of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can also be implemented by multiple units, or the function of multiple units can be implemented by one unit. For example, the functions implemented by the above units can be implemented by one processing unit. In other embodiments of this application, the data processing apparatus based on logical function division may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0222] According to another embodiment of this application, the following can be achieved by running on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM), a device capable of performing operations such as... Figure 4 as well as Figure 6 The computer program (including program code) for each step involved in the corresponding method shown, to construct such... Figure 18The data processing apparatus shown herein, and the data processing method for implementing the embodiments of this application, are described. The computer program may be recorded on, for example, a computer-readable storage medium, loaded onto the aforementioned computing device via the computer-readable storage medium, and run therein.

[0223] In this embodiment, a trusted execution node located outside the blockchain network and equipped with a built-in trusted execution environment can be used to partially respond to business requests initiated by clients. Specifically, the trusted execution node can receive business requests from clients; package the transactions carried by the business request into a target block within the trusted execution environment; execute the target block within the trusted execution environment to obtain the execution result; generate block data using the target block and the execution result; and then send the block data to the consensus nodes in the blockchain network. After the consensus nodes in the blockchain network reach a consensus on the block data, they store the block data in the blockchain. The processes involved in responding to business requests, such as packaging transactions and executing blocks, are executed by the trusted execution node outside the blockchain network, not by the consensus nodes in the blockchain network. The consensus nodes in the blockchain network store the block data, thus enabling off-chain computation and on-chain storage capabilities. This reduces the computational pressure on the blockchain network, thereby improving its stability. Furthermore, the reduced computational pressure lowers the hardware configuration requirements for the consensus nodes in the blockchain network, thereby saving on the hardware costs of the blockchain network. Furthermore, since the processes of packaging transactions and executing blocks occur within the trusted execution environment of trusted execution nodes, this environment is a secure zone isolated from the operating system of the trusted execution nodes. This protects the program code running within it from modification by other program code, ensuring that even if the target block and execution result are generated outside the blockchain network, they remain trustworthy. In summary, this reduces the computational burden on the blockchain network, thereby improving its stability. It also lowers the hardware requirements for consensus nodes in the blockchain network, thus saving on hardware costs.

[0224] Based on the aforementioned embodiments of the data processing method and the data processing device, this application also provides a second electronic device, which can be a consensus node in the aforementioned blockchain network. See also... Figure 19 This is a schematic diagram of the structure of a second electronic device provided in an embodiment of this application. Figure 19 The second electronic device shown may include at least a processor 1901, an input interface 1902, an output interface 1903, and a computer storage medium 1904. The processor 1901, input interface 1902, output interface 1903, and computer storage medium 1904 may be connected via a bus or other means.

[0225] The computer storage medium 1904 can be stored in the memory of the second electronic device. The computer storage medium 1904 is used to store computer programs, which include program instructions. The processor 1901 is used to execute the program instructions stored in the computer storage medium 1904. The processor 1901 (or CPU (Central Processing Unit)) is the computing and control core of the second electronic device. It is suitable for implementing one or more instructions, specifically for loading and executing one or more instructions to realize the above-mentioned data processing method flow or corresponding functions.

[0226] This application embodiment also provides a computer storage medium (Memory), which is a memory device in a second electronic device used to store programs and data. It is understood that the computer storage medium here can include the built-in storage medium in the terminal, or it can include an extended storage medium supported by the terminal. The computer storage medium provides storage space, which stores the terminal's operating system. Furthermore, the storage space also stores one or more instructions suitable for loading and execution by the processor 1901. These instructions can be one or more computer programs (including program code). It should be noted that the computer storage medium here can be a high-speed random access memory (RAM), or it can be non-volatile memory, such as at least one disk storage device; optionally, it can also be at least one computer storage medium located remotely from the aforementioned processor.

[0227] In one embodiment, processor 1901 may load and execute one or more instructions stored in computer storage medium to achieve the above. Figure 4 as well as Figure 6 In the data processing method embodiments, the corresponding steps executed by the consensus node are specifically implemented by one or more instructions in the computer storage medium, which are loaded and executed by the processor 1901 as follows:

[0228] The system receives block data generated by the trusted execution node. The block data includes a target block and an execution result. The target block is obtained by packaging the transaction carried by the transaction request initiated by the client in the trusted execution environment within the trusted execution node. The execution result is obtained by executing the target block in the trusted execution environment within the trusted execution node. The trusted execution node refers to a device located outside the blockchain network and equipped with a built-in trusted execution environment. The trusted execution environment within the trusted execution node is a secure area isolated from the operating system of the trusted execution node.

[0229] Consensus processing is performed on the block data, and after consensus is reached on the block data, the block data is stored in the blockchain.

[0230] In one embodiment, the block data further includes verification information used to verify whether at least one of the following objects is trustworthy: the trusted execution node, the target block, and the execution result; when the processor 1901 performs consensus processing on the block data, it performs the following operations:

[0231] Based on the verification information in the block data, the corresponding object is verified to obtain the object verification result;

[0232] If the object verification result indicates that the corresponding object is trustworthy, then consensus processing is performed on the target block and execution result in the block data.

[0233] In one embodiment, the trusted execution node packages transactions and executes blocks through a target application within a built-in trusted execution environment; the verification information includes a first remote authentication report, which is generated using the program attribute information of the target application used by the trusted execution node and the verification information of the program attribute information;

[0234] When the processor 1901 performs trusted verification on the corresponding object based on the verification information in the block data and obtains the object verification result, it performs the following operations:

[0235] The first remote authentication report is obtained from the verification information in the block data, and the validity of the program attribute information in the first remote authentication report is verified according to the verification information in the first remote authentication report to obtain the verification result.

[0236] If the verification result indicates that the program attribute information in the first remote authentication report is valid, then the target application used by the trusted execution node is trusted and verified according to the program attribute information in the first remote authentication report.

[0237] If the target application used by the trusted execution node passes the trusted verification, the trusted execution node is determined to be trusted; if the target application used by the trusted execution node fails the trusted verification, the trusted execution node is determined to be untrustworthy.

[0238] In one embodiment, the verification information includes the block hash value of the reference block; the reference block refers to the last block generated by the trusted execution node before generating the target block.

[0239] The processor 1901 verifies the validity of the program attribute information in the first remote authentication report based on the verification information in the first remote authentication report. When the verification result is obtained, the processor 1901 performs the following operations:

[0240] Obtain the block hash value of the last block on the blockchain in the local space, and perform a consistency comparison between the obtained block hash value and the block hash value in the first remote authentication report;

[0241] If the hash values ​​of the two blocks are the same, a verification result is generated to indicate that the program attribute information in the first remote authentication report is valid; if the hash values ​​of the two blocks are different, a verification result is generated to indicate that the program attribute information in the first remote authentication report is invalid.

[0242] In one embodiment, the target application used by the trusted execution node must be reviewed by an auditing platform before being deployed to the trusted execution environment within the trusted execution node; and the corresponding target application is deemed a trusted target application after passing the review by the auditing platform.

[0243] When the processor 1901 performs trusted verification on the target application used by the trusted execution node based on the program attribute information in the first remote authentication report, it performs the following operations:

[0244] Obtain a third remote authentication report about the trusted execution node from the auditing platform. The third remote authentication report includes: program attribute information of the target application that is allowed to be deployed in the trusted execution environment of the trusted execution node and has passed the audit.

[0245] The program attribute information in the third remote authentication report is compared with the program attribute information in the first remote authentication report for consistency.

[0246] If the attribute information of the two programs is consistent, it is determined that the target application used by the trusted execution node has passed the trusted verification; if the attribute information of the two programs is inconsistent, it is determined that the target application used by the trusted execution node has not passed the trusted verification.

[0247] In one embodiment, any consensus node has a built-in trusted execution environment, and based on the built-in trusted execution environment, any consensus node is qualified to serve as a backup node for the trusted execution node; the processor 1901 is further configured to:

[0248] After determining that the trusted execution node has failed, heartbeat information from other consensus nodes in the blockchain network is collected; any heartbeat information can be used to indicate the block height of the blockchain in the corresponding consensus node.

[0249] Based on the collected heartbeat information and the block height of the blockchain in any consensus node, a block synchronization requirement is detected; wherein, when the block height corresponding to any consensus node is lower than the block height corresponding to other consensus nodes, the consensus node has a block synchronization requirement.

[0250] If a block synchronization requirement is detected, block synchronization processing is performed between any of the consensus nodes and the other consensus nodes;

[0251] After completing the block synchronization process, it switches to a backup node of the trusted execution node and provides transaction packaging and block execution services based on the built-in trusted execution environment.

[0252] In one embodiment, after any consensus node switches to become a backup node of the trusted execution node, the processor 1901 is further configured to:

[0253] Receive a new business request initiated by the client, the new business request carrying a transaction;

[0254] The transaction carried by the new business request is packaged into a new block in the built-in trusted execution environment, and the new block is executed in the built-in trusted execution environment to obtain the corresponding execution result;

[0255] The new block data is generated using the new block and the corresponding execution result, and then broadcast to other consensus nodes in the blockchain network. After the other consensus nodes reach a consensus on the new block data, they store the new block data in the corresponding blockchain.

[0256] In one embodiment, the processor 1901 is further configured to:

[0257] Based on the time intervals of the various blocks of data historically sent by the trusted execution node, predict the time when the trusted execution node will send the next block of data.

[0258] If no block data is received from the trusted execution node after the predicted time has arrived, a probe request is sent to the trusted execution node, which is used to request the trusted execution node to return some data.

[0259] If no data is received from the trusted execution node within a preset time period, it is determined that the trusted execution node has failed.

[0260] This application provides a computer program product, which includes a computer program stored in a computer storage medium. A processor of a second electronic device reads the computer program from the computer storage medium and executes the computer program, causing the second electronic device to perform the aforementioned actions. Figure 4 as well as Figure 6 The steps performed by the consensus node in the illustrated method embodiment are shown below. The computer-readable storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0261] This application provides a data processing system, which includes a client, a trusted execution node, and a blockchain network, wherein the blockchain network includes consensus nodes; the trusted execution node refers to a device located outside the blockchain network and having a built-in trusted execution environment, wherein the trusted execution environment of the trusted execution node is a secure area isolated from the operating system of the trusted execution node; the method includes:

[0262] The client initiates a service request to the trusted execution node, and the service request carries a transaction.

[0263] The trusted execution node receives the business request initiated by the client, packages the transaction carried by the business request into a target block in the built-in trusted execution environment, and executes the target block in the built-in trusted execution environment to obtain the execution result;

[0264] The trusted execution node generates block data using the target block and the corresponding execution result, and sends the block data to the consensus nodes in the blockchain network;

[0265] The consensus nodes in the blockchain network perform consensus processing on the block data, and after reaching a consensus on the block data, store the block data in the blockchain.

[0266] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data processing method, characterized in that, The method is executed by a trusted execution node, which is a device located outside the blockchain network and equipped with a built-in trusted execution environment. This trusted execution environment is a secure area isolated from the operating system of the trusted execution node. The method includes: Receive a business request initiated by a client, the business request carrying a transaction; In the trusted execution environment, the transaction carried by the business request is packaged into a target block, and the target block is executed in the trusted execution environment to obtain the execution result; Block data is generated using the target block and the execution result, and the block data is sent to the consensus nodes in the blockchain network so that the consensus nodes in the blockchain network reach a consensus on the block data and then store the block data in the blockchain. The block data also includes verification information, which includes a first remote authentication report. The first remote authentication report is generated using the program attribute information of the target application used by the trusted execution node and the verification information of the program attribute information. The verification information includes the block hash value of a reference block. The reference block refers to the last block generated by the trusted execution node before generating the target block. The consensus node in the blockchain network determines whether the program attribute information is valid by comparing whether the block hash value of the reference block is consistent with the block hash value of the last block on the blockchain.

2. The method as described in claim 1, characterized in that, The step of generating block data using the target block and the execution result includes: Obtain verification information, which is used to verify whether at least one of the following objects is trustworthy: the trusted execution node, the target block, and the execution result; Block data is generated using the target block, the execution result, and the verification information; wherein, the consensus nodes in the blockchain network perform consensus processing on the target block and the execution result in the block data after verifying the trustworthiness of the corresponding object based on the verification information.

3. The method as described in claim 2, characterized in that, The target application runs in the trusted execution environment, and the trusted execution node packages transactions and executes blocks through the target application built into the trusted execution environment; The acquisition of verification information includes: Obtain the program attribute information of the target application in the trusted execution environment, and the program attribute information is used to verify whether the corresponding target application is trustworthy; Obtain the verification information of the program attribute information, the verification information being used to verify whether the program attribute information is valid; Using the program attribute information and the verification information, a first remote authentication report is generated, and the first remote authentication report is used as verification information; In this blockchain network, the consensus node verifies the trustworthiness of the target application in the trusted execution environment based on the program attribute information after determining its validity according to the verification information, thereby verifying the trustworthiness of the trusted execution node.

4. The method as described in claim 3, characterized in that, The program attribute information includes at least one of the following: the application metric of the target application in the trusted execution environment, and the application signature information of the target application in the trusted execution environment; wherein, the application metric is used to uniquely identify the target application in the trusted execution environment, and the application signature information is used to indicate the developer of the target application in the trusted execution environment.

5. The method according to any one of claims 2-4, characterized in that, The acquisition of verification information includes: The target block is signed using a first key to obtain the signature information of the target block; and the execution result is signed using a second key to obtain the signature information of the execution result. Both the signature information of the target block and the signature information of the execution result are used as verification information, so that the consensus nodes in the blockchain network can verify whether the target block is trustworthy based on the signature information of the target block, and verify whether the execution result is trustworthy based on the signature information of the execution result.

6. The method according to any one of claims 2-4, characterized in that, The blockchain network includes multiple consensus nodes; sending the block data to the consensus nodes in the blockchain network includes: The target consensus node is determined from the plurality of consensus nodes included in the blockchain network. The target consensus node refers to a consensus node with verification capabilities. The block data is sent to the target consensus node so that after the target consensus node verifies the trustworthiness of the corresponding object based on the verification information in the block data, it broadcasts the block data to the other consensus nodes, so that the other consensus nodes can perform consensus processing on the target block and execution result in the block data.

7. The method as described in claim 1, characterized in that, The target application runs in the trusted execution environment, and the trusted execution node packages transactions and executes blocks through the target application built into the trusted execution environment; The method further includes: The system receives a remote authentication request initiated by the client. The remote authentication request is used to verify whether the target application in the trusted execution environment is trustworthy, and the remote authentication request carries a random number. In response to the remote authentication request, the program attribute information of the target application in the trusted execution environment is obtained, and the program attribute information is used to verify whether the corresponding target application is trustworthy; A second remote authentication report is generated using the program attribute information, and the random number carried in the remote authentication request is added to the second remote authentication report so that the random number indicates that the second remote authentication report is a valid remote authentication report; The second remote authentication report is returned to the client so that after the client determines that the received second remote authentication report is valid, it verifies whether the corresponding target application is trustworthy based on the program attribute information in the second remote authentication report, thereby verifying whether the trusted execution node is trustworthy, and after determining that the trusted execution node is trustworthy, it initiates a transaction request to the trusted execution node.

8. A data processing method, characterized in that, The method is executed by any consensus node in the blockchain network, and the method includes: The system receives block data generated by a trusted execution node. The block data includes a target block and an execution result. The target block is obtained by packaging the transaction carried in a client-initiated transaction request within the trusted execution environment of the trusted execution node. The execution result is obtained by executing the target block within the trusted execution environment of the trusted execution node. The trusted execution node refers to a device located outside the blockchain network and equipped with a built-in trusted execution environment, which is a secure area isolated from the operating system of the trusted execution node. The block data also includes verification information, including a first remote authentication report generated using the program attribute information of the target application used by the trusted execution node and verification information of the program attribute information. The verification information includes the block hash value of a reference block. The reference block refers to the last block generated by the trusted execution node before generating the target block. The consensus node determines the validity of the program attribute information by comparing the block hash value of the reference block with the block hash value of the last block on the blockchain. Consensus processing is performed on the block data, and after consensus is reached on the block data, the block data is stored in the blockchain.

9. The method as described in claim 8, characterized in that, The verification information is used to verify whether at least one of the following objects is trustworthy: the trusted execution node, the target block, and the execution result; the consensus processing of the block data includes: Based on the verification information in the block data, the corresponding object is verified to obtain the object verification result; If the object verification result indicates that the corresponding object is trustworthy, then consensus processing is performed on the target block and execution result in the block data.

10. The method as described in claim 9, characterized in that, The trusted execution node packages transactions and executes blocks through the target application within the built-in trusted execution environment; The step of performing trusted verification on the corresponding object based on the verification information in the block data to obtain the object verification result includes: The first remote authentication report is obtained from the verification information in the block data, and the validity of the program attribute information in the first remote authentication report is verified according to the verification information in the first remote authentication report to obtain the verification result. If the verification result indicates that the program attribute information in the first remote authentication report is valid, then the target application used by the trusted execution node is trusted and verified according to the program attribute information in the first remote authentication report. If the target application used by the trusted execution node passes the trusted verification, the trusted execution node is determined to be trusted; if the target application used by the trusted execution node fails the trusted verification, the trusted execution node is determined to be untrustworthy.

11. The method as described in claim 10, characterized in that, The verification information includes the block hash value of the reference block; the reference block refers to the last block generated by the trusted execution node before generating the target block; The step of verifying the validity of the program attribute information in the first remote authentication report based on the verification information in the first remote authentication report, and obtaining the verification result, includes: Obtain the block hash value of the last block on the blockchain in the local space, and perform a consistency comparison between the obtained block hash value and the block hash value in the first remote authentication report; If the hash values ​​of the two blocks are the same, a verification result is generated to indicate that the program attribute information in the first remote authentication report is valid; if the hash values ​​of the two blocks are different, a verification result is generated to indicate that the program attribute information in the first remote authentication report is invalid.

12. The method as described in claim 10, characterized in that, Before being deployed to the trusted execution environment within the trusted execution node, the target application used by the trusted execution node must be reviewed by the review platform; and after passing the review by the review platform, the corresponding target application is identified as a trusted target application. The step of performing trusted verification on the target application used by the trusted execution node based on the program attribute information in the first remote authentication report includes: Obtain a third remote authentication report about the trusted execution node from the auditing platform. The third remote authentication report includes: program attribute information of the target application that is allowed to be deployed in the trusted execution environment of the trusted execution node and has passed the audit. The program attribute information in the third remote authentication report is compared with the program attribute information in the first remote authentication report for consistency. If the attribute information of the two programs is consistent, it is determined that the target application used by the trusted execution node has passed the trusted verification; if the attribute information of the two programs is inconsistent, it is determined that the target application used by the trusted execution node has not passed the trusted verification.

13. The method as described in claim 8, characterized in that, Each consensus node has a built-in trusted execution environment, and based on the built-in trusted execution environment, each consensus node is qualified to serve as a backup node for the trusted execution node; the method further includes: After determining that the trusted execution node has failed, heartbeat information from other consensus nodes in the blockchain network is collected; any heartbeat information can be used to indicate the block height of the blockchain in the corresponding consensus node. Based on the collected heartbeat information and the block height of the blockchain in any consensus node, a block synchronization requirement is detected; wherein, when the block height corresponding to any consensus node is lower than the block height corresponding to other consensus nodes, the consensus node has a block synchronization requirement. If a block synchronization requirement is detected, block synchronization processing is performed between any of the consensus nodes and the other consensus nodes; After completing the block synchronization process, it switches to a backup node of the trusted execution node and provides transaction packaging and block execution services based on the built-in trusted execution environment.

14. The method as described in claim 13, characterized in that, After any consensus node is switched to become a backup node of the trusted execution node, the method further includes: Receive a new business request initiated by the client, the new business request carrying a transaction; The transaction carried by the new business request is packaged into a new block in the built-in trusted execution environment, and the new block is executed in the built-in trusted execution environment to obtain the corresponding execution result; The new block data is generated using the new block and the corresponding execution result, and then broadcast to other consensus nodes in the blockchain network. After the other consensus nodes reach a consensus on the new block data, they store the new block data in the corresponding blockchain.

15. The method as described in claim 13, characterized in that, The method further includes: Based on the time intervals of the various blocks of data historically sent by the trusted execution node, predict the time when the trusted execution node will send the next block of data. If no block data is received from the trusted execution node after the predicted time has arrived, a probe request is sent to the trusted execution node, which is used to request the trusted execution node to return some data. If no data is received from the trusted execution node within a preset time period, it is determined that the trusted execution node has failed.

16. A data processing system, characterized in that, The data processing system includes a client, a trusted execution node, and a blockchain network, the blockchain network including consensus nodes; the trusted execution node refers to a device located outside the blockchain network and having a built-in trusted execution environment, the trusted execution environment of the trusted execution node being a secure area isolated from the operating system of the trusted execution node; The client initiates a service request to the trusted execution node, and the service request carries a transaction. The trusted execution node receives the business request initiated by the client, packages the transaction carried by the business request into a target block in the built-in trusted execution environment, and executes the target block in the built-in trusted execution environment to obtain the execution result; The trusted execution node generates block data using the target block and the corresponding execution result, and sends the block data to the consensus nodes in the blockchain network; The consensus nodes in the blockchain network perform consensus processing on the block data, and after reaching a consensus on the block data, store the block data in the blockchain. The block data also includes verification information, which includes a first remote authentication report. The first remote authentication report is generated using the program attribute information of the target application used by the trusted execution node and the verification information of the program attribute information. The verification information includes: the block hash value of the reference block; the reference block refers to: the last block generated by the trusted execution node before generating the target block; wherein, the consensus node in the blockchain network determines whether the program attribute information is valid by comparing whether the block hash value of the reference block is consistent with the block hash value of the last block on the blockchain.

17. A data processing apparatus, characterized in that, The device operates within a trusted execution node, which is a device located outside the blockchain network and equipped with a built-in trusted execution environment. This trusted execution environment is a secure area isolated from the operating system of the trusted execution node. The device includes: The receiving unit is used to receive a business request initiated by a client, wherein the business request carries a transaction. The processing unit is configured to package the transactions carried by the business request into a target block in the trusted execution environment, and execute the target block in the trusted execution environment to obtain the execution result; The processing unit is further configured to generate block data using the target block and the execution result; A sending unit is configured to send the block data to consensus nodes in the blockchain network, so that after the consensus nodes in the blockchain network reach a consensus on the block data, the block data is stored in the blockchain; the block data also includes verification information, the verification information including a first remote authentication report, which is generated using the program attribute information of the target application used by the trusted execution node and the verification information of the program attribute information; the verification information includes the block hash value of a reference block; the reference block refers to the last block generated by the trusted execution node before generating the target block; the consensus node determines whether the program attribute information is valid by comparing whether the block hash value of the reference block is consistent with the block hash value of the last block on the blockchain.

18. A data processing apparatus, characterized in that, The device operates on any consensus node in the blockchain network, and the device includes: A receiving unit is configured to receive block data generated by a trusted execution node. The block data includes a target block and an execution result. The target block is obtained by packaging the transaction carried in a client-initiated transaction request within the trusted execution environment of the trusted execution node. The execution result is obtained by executing the target block within the trusted execution environment of the trusted execution node. The trusted execution node refers to a device located outside the blockchain network and equipped with a built-in trusted execution environment. The trusted execution environment within the trusted execution node is a secure area isolated from the operating system of the trusted execution node. The block data also includes verification information, including a first remote authentication report generated using the program attribute information of the target application used by the trusted execution node and verification information of the program attribute information. The verification information includes the block hash value of a reference block. The reference block refers to the last block generated by the trusted execution node before generating the target block. The consensus node determines the validity of the program attribute information by comparing the block hash value of the reference block with the block hash value of the last block on the blockchain. The processing unit is used to perform consensus processing on the block data, and after reaching a consensus on the block data, store the block data in the blockchain.

19. A first electronic device, characterized in that, The first electronic device includes an input interface and an output interface, and further includes: A processor, adapted to implement one or more instructions; and, A computer storage medium storing one or more instructions adapted to be loaded by the processor and executed as described in any one of claims 1-7.

20. A second electronic device, characterized in that, The second electronic device includes an input interface and an output interface, and further includes: A processor, adapted to implement one or more instructions; and, A computer storage medium storing one or more instructions adapted to be loaded by the processor and executed as described in any one of claims 8-15.

Images