Data processing method and device based on trusted execution environment, equipment and medium

Abstract

The invention discloses a data processing method and device based on a trusted execution environment, equipment and a medium. The method comprises the steps of obtaining multi-signature signature information associated with an approval object; performing signature verification on the approval signature information through the public key information of the approval object, configuring the approval state of the resource transfer transaction as an approval passing state when the signature verification is successful, and performing transaction signature on the resource transfer transaction through environment private key information configured by the trusted execution environment to obtain first transaction signature information; sending the first transaction signature information to a resource client, so that the resource client determines a signed resource transfer transaction based on the first transaction signature information and second transaction signature information obtained after the resource transfer transaction is signed through the private key information of the first business object, and sending the signed resource transfer transaction to a block chain node in the block chain network. By adopting the application, the reliability of the under-chain approval process and the security of the transaction on-chain can be improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular, to a data processing method, apparatus, device, and medium based on a trusted execution environment. Background Art

[0002] Currently, before transferring business resources, a designated approval object can conduct transaction approval on relevant resource transfer transactions, and the business resources can be transferred only after the approval is passed. Currently, there are two mainstream transaction approval schemes: one is an off-chain approval scheme, that is, placing the approval process off-chain and deciding whether to put the resource transfer transaction on the chain according to the approval result of the resource transfer transaction approved off-chain; the other is an on-chain approval scheme, that is, placing the approval process in an on-chain smart contract and verifying whether the resource transfer transaction passes the approval through the smart contract.

[0003] However, the inventor found in practice that in the off-chain approval scheme, the approval result is invisible on the chain, and the node executing the transaction on the chain can decide on its own whether the resource transfer transaction passes the approval. Even in the case of non-approval, it may bypass the approval object and directly put the resource transfer transaction on the chain, resulting in an untrusted off-chain approval process and difficulty in ensuring the security of the transaction on the chain; in the on-chain approval scheme, in addition to putting the resource transfer transaction on the chain, it is also necessary to put on the chain the transactions submitted by each approval object after conducting transaction approval on the resource transfer transaction, so that more transactions need to be stored additionally on the blockchain and more verification logics need to be called by the smart contract, resulting in a very large approval overhead required for a single resource transfer. Summary of the Invention

[0004] The embodiments of this application provide a data processing method, apparatus, device, and medium based on a trusted execution environment, which can improve the reliability of the off-chain approval process and the security of the transaction on the chain, and can reduce the approval overhead.

[0005] On the one hand, the embodiments of this application provide a data processing method based on a trusted execution environment. The method is executed by an approval client, and the approval client runs in a trusted execution environment. The method includes:

[0006] Obtain multi-signature information associated with an approval object; the multi-signature information includes approval signature information obtained after the approval terminal conducts transaction approval on the resource transfer transaction; the approval signature information is obtained after the approval terminal conducts transaction signature on the resource transfer transaction through the private key information of the approval object; the resource transfer transaction refers to a transaction initiated by a first business object through a resource client for transferring business resources to a second business object;

[0007] Obtain the public key information of the approval object from the trusted execution environment, verify the signature of the approval signature information through the public key information of the approval object, and when the signature verification is successful, configure the approval status of the resource transfer transaction to the approved status. Sign the resource transfer transaction in the approved status through the environment private key information configured by the trusted execution environment to obtain the first transaction signature information;

[0008] Send the first transaction signature information to the resource client, so that the resource client signs the resource transfer transaction through the private key information of the first business object to obtain the second transaction signature information, determine the signed resource transfer transaction corresponding to the resource transfer transaction based on the first transaction signature information and the second transaction signature information, and send the signed resource transfer transaction to the blockchain node in the blockchain network; The signed resource transfer transaction is used to instruct the blockchain node to verify the signatures of the first transaction signature information and the second transaction signature information through the environment public key information corresponding to the environment private key information and the public key information of the first business object, and when the signature verification is successful, transfer the business resources from the account address of the first business object to the account address of the second business object.

[0009] An embodiment of the present application provides a data processing method based on a trusted execution environment on the one hand. The method is executed by a blockchain node in a blockchain network. The method includes:

[0010] Obtain the signed resource transfer transaction corresponding to the resource transfer transaction; The resource transfer transaction refers to a transaction initiated by the first business object through the resource client for transferring business resources to the second business object; The signed resource transfer transaction is determined based on the first transaction signature information and the second transaction signature information when the resource client signs the resource transfer transaction through the private key information of the first business object to obtain the second transaction signature information; The first transaction signature information is obtained after the resource client signs the resource transfer transaction in the approved status through the environment private key information configured by the trusted execution environment; The approved status is obtained after the resource client configures the approval status of the resource transfer transaction by verifying the signature of the approval signature information through the public key information of the approval object obtained from the trusted execution environment and when the signature verification is successful; The approval signature information is obtained after the approval terminal signs the resource transfer transaction through the private key information of the approval object; The multi-signature information associated with the approval object includes the approval signature information obtained after the approval terminal approves the resource transfer transaction;

[0011] Verify the signature of the second transaction signature information using the public key information of the first business object, and when the signature verification is successful, obtain the environmental public key information corresponding to the environmental private key information from the resource business contract associated with the resource client; the resource business contract is deployed on the blockchain corresponding to the blockchain network;

[0012] Verify the signature of the first transaction signature information using the environmental public key information, and when the signature verification is successful, transfer the business resources from the account address of the first business object to the account address of the second business object through the resource business contract.

[0013] On the one hand, an embodiment of the present application provides a data processing device based on a trusted execution environment. The device runs on an approval client, and the approval client runs in a trusted execution environment. The device includes:

[0014] A signature acquisition module for acquiring multi-signature information associated with an approval object; the multi-signature information includes approval signature information obtained after the approval terminal approves a resource transfer transaction; the approval signature information is obtained after the approval terminal signs the resource transfer transaction using the private key information of the approval object; the resource transfer transaction is a transaction initiated by a first business object through a resource client for transferring business resources to a second business object;

[0015] An approval verification module for obtaining the public key information of the approval object from the trusted execution environment, verifying the signature of the approval signature information using the public key information of the approval object, and when the signature verification is successful, configuring the approval status of the resource transfer transaction to the approved status, and signing the resource transfer transaction in the approved status using the environmental private key information configured by the trusted execution environment to obtain the first transaction signature information;

[0016] A signature sending module for sending the first transaction signature information to the resource client, so that the resource client signs the resource transfer transaction using the private key information of the first business object to obtain the second transaction signature information, determining the signed resource transfer transaction corresponding to the resource transfer transaction based on the first transaction signature information and the second transaction signature information, and sending the signed resource transfer transaction to the blockchain node in the blockchain network; the signed resource transfer transaction is used to instruct the blockchain node to verify the signatures of the first transaction signature information and the second transaction signature information using the environmental public key information corresponding to the environmental private key information and the public key information of the first business object, and when the signature verification is successful, transfer the business resources from the account address of the first business object to the account address of the second business object.

[0017] Wherein, the multi-signature information includes the approval signature information of M approval objects; M is a positive integer;

[0018] The approval verification module includes:

[0019] An approval verification unit, configured to obtain the public key information of M approval objects from a trusted execution environment, and verify the approval signature information of the M approval objects through the public key information of the M approval objects to obtain the approval verification results corresponding to the M approval signature information; the approval verification results include the verification success result or the verification failure result corresponding to each approval signature information in the M approval signature information.

[0020] An approval passing unit, configured to determine that the signature verification is successful when the number of verification success results in the approval verification results meets the approval passing conditions configured by the approval client.

[0021] Among them, the approval passing conditions include an approval quantity threshold.

[0022] Specifically, the approval passing unit is configured to determine that the signature verification is successful when the number of verification success results in the approval verification results is greater than or equal to the approval quantity threshold.

[0023] Among them, the approval passing conditions include an approval ratio threshold.

[0024] Specifically, the approval passing unit is configured to obtain the verification success ratio between the number of verification success results in the approval verification results and the total number of approval objects; the total number of approval objects is a positive integer greater than or equal to M; when the verification success ratio is greater than or equal to the approval ratio threshold, determine that the signature verification is successful.

[0025] Among them, the apparatus further includes:

[0026] A first proof obtaining module, configured to obtain a first remote proof corresponding to the approval passing status, and send the first remote proof to the resource client, so that when the resource client sends a signed resource transfer transaction to the blockchain node, the first remote proof is sent to the blockchain node; the first remote proof is used to be written into a resource business contract deployed on the blockchain corresponding to the blockchain network.

[0027] Among them, the first proof obtaining module includes:

[0028] A signature generation unit, configured to obtain first service information associated with the approval passing status, the program measurement value of the approval client, and environment parameter information associated with the trusted execution environment, and sign the first service information, the program measurement value, and the environment parameter information through the environment private key information to obtain first proof signature information;

[0029] A proof determination unit, configured to determine a first remote proof corresponding to the approval passing status based on the first service information, the program measurement value, the environment parameter information, and

[0030] the first proof signature information.

[0031] Specifically, the signature generation unit is configured to splice the first service information, the program measurement value, and the environment parameter information to obtain first spliced data; and sign the first spliced data with the environment private key information to obtain first proof signature information.

[0032] The apparatus further includes:

[0033] A second proof acquisition module, configured to, when receiving a proof generation request sent by a first service object through a resource client, obtain the program measurement value of an approval client and environment parameter information associated with a trusted execution environment based on the proof generation request, and obtain second service information associated with the first service object from the proof generation request; sign the program measurement value, the second service information, and the environment parameter information with the environment private key information to obtain second proof signature information; determine a second remote proof corresponding to the approval client based on the program measurement value, the second service information, the environment parameter information, and the second proof signature information, and send the second remote proof to the resource client, so that the resource client sends the second remote proof to a remote authentication server for remote authentication.

[0034] The apparatus further includes:

[0035] A third proof acquisition module, configured to, when the signature verification fails, configure the approval status of the resource transfer transaction as a non-approved status, obtain a third remote proof corresponding to the non-approved status, and generate a transfer failure prompt message based on the non-approved status, and send the third remote proof and the transfer failure prompt message to the resource client.

[0036] One aspect of the embodiments of the present application provides a data processing apparatus based on a trusted execution environment. The apparatus runs on a blockchain node in a blockchain network. The apparatus includes:

[0037] A transaction acquisition module for acquiring a signed resource transfer transaction corresponding to a resource transfer transaction; the resource transfer transaction refers to a transaction initiated by a first business object through a resource client for transferring business resources to a second business object; the signed resource transfer transaction is determined based on a first transaction signature information and a second transaction signature information when the resource client signs the resource transfer transaction with the private key information of the first business object to obtain the second transaction signature information; the first transaction signature information is obtained after the resource client signs the resource transfer transaction in an approved state with the environment private key information configured by a trusted execution environment; the approved state is obtained after the resource client verifies the signature of the approval signature information with the public key information of the approval object obtained from the trusted execution environment and configures the approval state of the resource transfer transaction when the signature verification is successful; the approval signature information is obtained after the approval terminal signs the resource transfer transaction with the private key information of the approval object; the multi-signature information associated with the approval object includes the approval signature information obtained after the approval terminal approves the resource transfer transaction.

[0038] A first verification module for verifying the signature of the second transaction signature information with the public key information of the first business object, and when the signature verification is successful, obtaining the environment public key information corresponding to the environment private key information from the resource business contract associated with the resource client; the resource business contract is deployed on the blockchain corresponding to the blockchain network.

[0039] A second verification module for verifying the signature of the first transaction signature information with the environment public key information, and when the signature verification is successful, transferring the business resources from the account address of the first business object to the account address of the second business object through the resource business contract.

[0040] Among them, the second verification module includes:

[0041] A signature verification unit for verifying the signature of the first transaction signature information with the environment public key information to obtain the to-be-verified digest information of the resource transfer transaction; when obtaining the transaction digest information of the resource transfer transaction, comparing the to-be-verified digest information with the transaction digest information, and if the to-be-verified digest information is consistent with the transaction digest information, determining that the signature verification is successful.

[0042] A resource transfer unit for transferring the business resources from the account address of the first business object to the account address of the second business object through the resource business contract.

[0043] Among them, the device further includes:

[0044] A proof authentication module, which is configured to, when receiving a proof acquisition request sent by a first service object through a resource client, call a resource service contract based on the proof acquisition request, obtain a first remote proof corresponding to an approved status, and send the first remote proof to the resource client, so that the resource client sends the first remote proof to a remote authentication server for remote authentication.

[0045] On the one hand, an embodiment of the present application provides a computer device, including: a processor and a memory;

[0046] The processor is connected to the memory. Among them, the memory is used to store a computer program. When the computer program is executed by the processor, the computer device is enabled to execute the method provided by the embodiment of the present application.

[0047] On the one hand, an embodiment of the present application provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and the computer program is suitable for being loaded and executed by a processor, so that a computer device having the processor executes the method provided by the embodiment of the present application.

[0048] On the one hand, an embodiment of the present application provides a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method provided by the embodiment of the present application.

[0049] In the embodiment of the present application, an approval client running in a trusted execution environment can obtain multi-signature information associated with an approval object; wherein, the multi-signature information includes approval signature information obtained after the approval terminal approves a resource transfer transaction; the approval signature information is obtained after the approval terminal signs the resource transfer transaction with the private key information of the approval object; the resource transfer transaction is a transaction initiated by a first business object through a resource client for transferring business resources to a second business object; further, the public key information of the approval object can be obtained from the trusted execution environment, the approval signature information is verified by the public key information of the approval object, and when the signature verification is successful, the approval status of the resource transfer transaction is configured as the approved status, and the resource transfer transaction in the approved status is signed with the environment private key information configured by the trusted execution environment to obtain the first transaction signature information; furthermore, the first transaction signature information can be sent to the resource client, so that the resource client signs the resource transfer transaction with the private key information of the first business object to obtain the second transaction signature information, and the signed resource transfer transaction corresponding to the resource transfer transaction is determined based on the first transaction signature information and the second transaction signature information, and the signed resource transfer transaction is sent to a blockchain node in the blockchain network; wherein, the signed resource transfer transaction here can be used to instruct the blockchain node to verify the first transaction signature information and the second transaction signature information by the environment public key information corresponding to the environment private key information and the public key information of the first business object, and when the signature verification is successful, transfer the business resources from the account address of the first business object to the account address of the second business object. It can be seen that the embodiment of the present application provides an off-chain transaction approval scheme based on a trusted execution environment. Since the approval client runs in the trusted execution environment, the correctness and immutability of the approval logic can be ensured through the trusted execution environment, solving the untrusted problem brought by off-chain approval. That is to say, placing the approval process in the trusted execution environment off-chain can improve the reliability of the off-chain approval process. When the subsequent blockchain node successfully verifies the relevant signature information (i.e., the aforementioned first transaction signature information and second transaction signature information) of the signed resource transfer transaction by invoking the resource business contract, it can confirm that the resource transfer transaction on the chain has been approved, which is equivalent to the blockchain nodes jointly witnessing the approval process of the resource transfer transaction, thereby improving the security of the transaction on the chain. In addition, when transferring resources, only the signature information (i.e., the aforementioned first transaction signature information) of the resource transfer transaction signed with the built-in key (i.e., the aforementioned environment private key information) of the trusted execution environment needs to be attached, and the transfer of relevant business resources can be achieved through one transaction (i.e., the aforementioned signed resource transfer transaction), without the need to upload additional transactions to the chain, reducing the data storage and verification pressure on the blockchain, saving the handling fees required for approval, and thus reducing the overall approval cost. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0051] Figure 1 is a schematic diagram of a system architecture provided by an embodiment of the present application;

[0052] Figure 2a is a schematic diagram of a data processing scenario based on a trusted execution environment provided by an embodiment of the present application Figure 1 ;

[0053] Figure 2b is the second schematic diagram of a data processing scenario based on a trusted execution environment provided by an embodiment of the present application;

[0054] Figure 3 is the flowchart of a data processing method based on a trusted execution environment provided by an embodiment of the present application Figure 1 ;

[0055] Figure 4 is a schematic diagram of an off-chain approval scenario based on a trusted execution environment provided by an embodiment of the present application;

[0056] Figure 5 is the second flowchart of a data processing method based on a trusted execution environment provided by an embodiment of the present application;

[0057] Figure 6 is a schematic diagram of a scenario for obtaining a first remote attestation provided by an embodiment of the present application;

[0058] Figure 7 is a schematic diagram of a scenario for obtaining a second remote attestation provided by an embodiment of the present application;

[0059] Figure 8 is a schematic diagram of a scenario for obtaining a third remote attestation provided by an embodiment of the present application;

[0060] Figure 9 is the flowchart of a data processing method based on a trusted execution environment provided by an embodiment of the present application Figure 3 ;

[0061] Figure 10 is a schematic diagram of a transfer process based on a trusted execution environment provided by an embodiment of the present application;

[0062] Figure 11The structural schematic diagram of a data processing device based on a trusted execution environment provided by an embodiment of the present application Figure 1 ;

[0063] Figure 12 It is the second structural schematic diagram of a data processing device based on a trusted execution environment provided by an embodiment of the present application;

[0064] Figure 13 It is the structural schematic diagram of a computer device provided by an embodiment of the present application;

[0065] Figure 14 It is the structural schematic diagram of a data processing system based on a trusted execution environment provided by an embodiment of the present application. Detailed implementation manners

[0066] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the protection scope of the present application.

[0067] Please refer to Figure 1 , Figure 1 It is the schematic diagram of a system architecture provided by an embodiment of the present application. As Figure 1 shown, the system architecture may include a blockchain network 100 and a terminal cluster. Among them, the terminal cluster may include multiple terminal devices (which may be simply referred to as terminals), and the embodiment of the present application does not limit the number of terminal devices included in the terminal cluster. For example, the terminal cluster may specifically include: terminal device 200a, terminal device 200b, terminal device 200c,..., terminal device 200n. Among them, there may be a communication connection between the terminal clusters. For example, there is a communication connection between terminal device 200a and terminal device 200b, and there is a communication connection between terminal device 200a and terminal device 200c. Among them, the communication connection here does not limit the connection method, and it can be directly or indirectly connected through a wired communication method, or directly or indirectly connected through a wireless communication method, or through other methods, which are not limited in the embodiment of the present application.

[0068] Among them, the above-mentioned terminal devices may be intelligent terminals such as smart phones, tablet computers, laptop computers, desktop computers, desktop computers, palm computers, mobile internet devices (MID), wearable devices (such as smart watches, smart helmets, etc.), intelligent computers, smart homes, and smart vehicles. It should be understood that as Figure 1Each terminal device in the shown terminal cluster can be installed with a client. When the client runs on each terminal device, it can respectively perform data interaction with the blockchain network 100 shown above. Figure 1 Among them, the client can be a financial client (for example, a resource client, a payment client, a shopping client), an entertainment client (for example, a game client, a live broadcast client, a novel client), a multimedia client (for example, a video client, a music client), a vehicle-mounted client, a smart home client, a browser, etc., which are application programs with the function of displaying data information such as text, images, videos, and audio. Among them, the client can be an independent client or an embedded sub-client integrated in a certain client (such as a payment client, etc.), which is not limited here. Taking the payment client as an example, the terminal device 200a can transmit data with other terminal devices and the blockchain network 100 through the payment client running on it. For example, the terminal device 200a can initiate a transfer request to a blockchain node in the blockchain network 100 through the payment client, so as to transfer to a specified account address and notify the corresponding terminal device (such as the terminal device 200b).

[0069] Among them, terminal devices can be roughly divided into two terminal types according to their operation methods. For the convenience of distinction, they can be respectively called the first terminal type and the second terminal type here. Among them, a terminal device with the first terminal type (which can also be called a desktop device or a desktop-oriented terminal device) refers to a terminal device mainly based on interactive operations such as mouse clicks and keyboard inputs. Any client running on such a terminal device usually supports opening one or more windows simultaneously (that is, supports multi-page display). Therefore, such terminal devices have the characteristic of interacting in terms of windows. Terminal devices with the first terminal type can include laptops, desktop computers, smart computers, some tablets (such as Microsoft's Surface Pro, which can be operated with an external keyboard and mouse), etc.; while a terminal device with the second terminal type (which can also be called a non-desktop device) refers to a terminal device mainly based on interactive operations such as user hand clicks or swipes. Any client running on such a terminal device usually can only open one window (that is, supports single-page display). Terminal devices with the second terminal type can include smart phones, some tablets (such as iPad), mobile Internet devices, wearable devices (such as smart watches, smart bracelets, etc.), intelligent vehicles, etc. Based on this, the embodiments of this application can also divide the clients installed and running on different terminal types into two client types. Among them, the client type of the client installed and running on a terminal device with the first terminal type can be called the first client type (that is, a desktop-oriented client, which can also be called a non-mobile end, such as a computer end), and the client type of the client installed and running on a terminal device with the second terminal type can be called the second client type (that is, a mobile end, such as a mobile phone end). For two different client types of the same application, there may also be certain differences in their page layouts and interaction methods. The method provided in this application is applicable to all client types. Therefore, all embodiments of this application do not limit the terminal types of the terminal devices involved, nor do they limit the client types of the clients involved, and subsequent descriptions will not distinguish the differences in the page layouts and interaction methods of different client types.

[0070] It can be understood that blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithms. It is mainly used to sort data in chronological order, encrypt it into a ledger, make it tamper-proof and forgery-proof, and at the same time, data verification, storage, and update can be carried out. Blockchain is a chain composed of one block after another. Each block stores certain information, and they are connected into a chain according to the chronological order of their generation. Blockchain is essentially a decentralized database, and each node in this database stores the same blockchain. As long as one node in the entire database can work, the entire blockchain is secure. For exampleFigure 1 The blockchain network 100 shown can be applied to a blockchain system, which refers to a system for data sharing between blockchain nodes. The blockchain network 100 can be deployed with multiple blockchain nodes (which can be abbreviated as nodes), and the number of blockchain nodes deployed in the blockchain network 100 will not be limited here. For example, as Figure 1 shown, the blockchain network 100 can specifically include node 100a, node 100b, node 100c, node 100d, …, node 100m. Among them, the blockchain node can be a server accessing the blockchain network or a terminal accessing the blockchain network. The specific form of the blockchain node is not limited here. Each blockchain node can include a hardware layer, an intermediate layer, an operating system layer, and an application layer. Any terminal device in the above terminal cluster can have a communication connection with any blockchain node in the blockchain network 100. For example, there is a communication connection between the terminal device 200a and the node 100a. Among them, the communication connection here does not limit the connection method, and it can be directly or indirectly connected through a wired communication method, or directly or indirectly connected through a wireless communication method, or through other methods, which are not limited in the embodiments of the present application.

[0071] Among them, the above server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud databases, cloud services, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0072] It should be noted that the blockchain network in the embodiments of the present application can be a hierarchical structure or a single-layer structure, and the specific structure of the blockchain network is not limited here.

[0073] For example, optionally, for a blockchain network with a hierarchical structure, Figure 1 the blockchain network 100 shown can be further divided into a business network (i.e., a witness network) and a core consensus network, and the business network and the core consensus network are independent of each other. Among them, multiple nodes can be deployed in both the business network and the core consensus network, and the number of nodes deployed in the two networks will not be limited here. For example, the business network can include Figure 1 the nodes 100a, 100b, and 100c shown, and the core consensus network can include Figure 1The nodes 100d, 100e, …, 100m shown. Among them, the nodes in the business network can be called business nodes, and the business nodes here are mainly used to execute transaction services to obtain transaction data associated with the transaction service and perform data clearing and synchronization in a timely manner. It can be understood that the business nodes do not need to participate in the accounting consensus, but can obtain the block header data and partially authorized visible block data from the core consensus network through identity authentication. Among them, the business node can be a full node (Full Node) containing a complete blockchain database, or a lightweight node (Lightweight Node) storing part of the data in the blockchain database. Such nodes can complete transaction verification through the "Simplified Payment Verification (SPV)" method, so they can also be called SPV nodes. The types of business nodes will not be limited here. Similarly, the nodes in the core consensus network can be called consensus nodes (also called core nodes, that is, accounting nodes), and the consensus nodes here can run the blockchain consensus protocol. Among them, the consensus node can be a full node containing a complete blockchain database. The consensus node can participate in verifying and broadcasting transaction data and block information, and will discover and maintain connections with other nodes. In addition, optionally, the business network and the core consensus network can be network-isolated through a routing network (i.e., a routing proxy layer). For example, through the routing nodes in the routing network, the peer-to-peer network can be network-layered to form a hierarchical structure of "business network - core consensus network", thereby improving the confidentiality and security of the data on the blockchain. The number of routing nodes in the routing network can be one or more, which is not limited here.

[0074] It can be understood that the above-mentioned business network and core consensus network can be in different network environments. For example, in some embodiments, the business nodes can be deployed in the business network in the public network, while the consensus nodes running the blockchain consensus protocol can be deployed in the private core consensus network, and the two can interact through the routing boundary. In this case, since the core consensus network is in a relatively secure private cloud, the mutual access between them already has a consensus mechanism to ensure security and does not require additional identity management and network control; while the business nodes are in the public network and may be accessed by other uncertain network terminals, so the behavior of the business nodes and other possible nodes accessing the core consensus network needs to be strictly controlled. Optionally, in some other embodiments, the business nodes and the consensus nodes can also directly transmit data without passing through the routing nodes, which is not limited here.

[0075] For another example, optionally, for a blockchain network with a single-layer structure Figure 1The blockchain network 100 shown may include consensus nodes and ordinary nodes. The consensus nodes participate in consensus, while the ordinary nodes do not participate in consensus, but can help spread block and voting messages, and synchronize states with each other, etc. For example, nodes 100a, 100b, 100c, and 100d in Figure 1 can be used as consensus nodes, and the remaining nodes can be used as ordinary nodes. Here, the number of consensus nodes and the number of ordinary nodes are not limited.

[0076] In the above blockchain system, the consensus nodes can be responsible for consensus in the blockchain network (such as blockchain network 100) where the corresponding blockchain is located. For the above blockchain network 100, the specific process of writing the transaction data in the blockchain network 100 into the corresponding blockchain ledger (for example, a distributed database) can be that the user client sends the transaction data to a non-consensus node (such as a business node or an ordinary node), and then the transaction data is passed among the non-consensus nodes in the above blockchain network 100 in a relay manner until the consensus node (such as node 100d) in the above blockchain network 100 receives the transaction data. At this time, the consensus node packs the transaction data into a block so that it can perform consensus with other consensus nodes subsequently, and thus, after the consensus is passed, the block passed by the consensus can be written into the distributed database of the blockchain network 100.

[0077] Optionally, it can be understood that after the consensus is passed, the consensus node can also write the block carrying the transaction data and multiple other blocks associated with the block into the distributed database in parallel through the storage layer of its own blockchain network 100 (for example, the core consensus network under a hierarchical structure). In this way, the limitation of the blockchain structure of the blockchain can be broken through from the root, and thus the storage efficiency of data storage can be effectively improved.

[0078] In the embodiments of the present application, all nodes in the blockchain network (such as the foregoing consensus nodes, business nodes, and ordinary nodes) can be collectively referred to as blockchain nodes. Among them, the embodiments of the present application can configure a blockchain node for any role (such as any individual user, any enterprise, any institution, etc., entity objects) accessing the blockchain network. For example, assume that Figure 1 nodes 100a, 100b, and 100c in the blockchain network 100 shown are all business nodes, then there can be a one-to-one correspondence between nodes 100a, 100b, and 100c and the corresponding roles that need to access the blockchain network 100, and the blockchain nodes associated with different roles can be the same blockchain node.

[0079] It can be understood that a smart contract can be deployed in the above blockchain system. In the blockchain system, the smart contract can be understood as a piece of code that can be understood and executed by each node of the blockchain (such as a consensus node), and can execute any logic and obtain results. In practical applications, the smart contract can be managed and used through transactions on the blockchain. Each transaction is equivalent to an RPC (Remote Procedure Call) request to the blockchain system. For example, an entity object (such as a user requesting to execute a transaction service) can initiate a contract call request (also known as a transaction service request) through the client on its held terminal device (such as the above terminal device 200a), and call a relevant business contract that has been deployed on the blockchain (such as the blockchain corresponding to the above blockchain network 100). The blockchain system can include one or more smart contracts, and these smart contracts can be distinguished by contract identifiers. In the contract call request initiated by the client, the contract identifier of the smart contract can be carried to specify the smart contract that the blockchain needs to run. Among them, the contract identifier can include, but is not limited to, the contract identifier number of the smart contract (i.e., contract ID, where ID is the abbreviation of Identity document), contract name, contract address, contract function name (also can be called contract method name), etc. Here, the specific form of the contract identifier will not be limited.

[0080] In view of the defects existing in the current transaction approval scheme, the embodiment of the present application provides an off-chain transaction approval scheme based on a trusted execution environment, which can improve the reliability of the off-chain approval process and the security of transaction on-chain, and can reduce the approval overhead. Among them, the embodiment of the present application involves a resource client. Here, the resource client can run on a terminal device (which can be called a business terminal) and is a tool for managing and storing user digital resources. For example, digital resources can be transferred to other accounts based on the resource client, and for another example, digital resources transferred from other accounts can be received based on the resource client. The resource client can be a hardware device or a software program. Here, the digital resources can also be called digital assets, which refer to the assets or resources stored on the blockchain, can be transferred between different account addresses on the chain, and the security of the digital resources can be ensured by encrypting them. Through the digital resource standard (or standard resource issuance protocol) based on the blockchain, users can efficiently, reliably and low-costly create digital resources exclusive to their own projects on the chain. When the resource client runs on such as Figure 1When on any terminal device (such as terminal device 200a) in the shown terminal cluster, data interaction can occur between the resource client and the blockchain nodes in the blockchain network 100. For example, the resource client can send a transaction to be chained to a blockchain node (such as a consensus node) in the blockchain network 100. Finally, each blockchain node will verify whether the transaction execution results are consistent with each other (that is, perform consensus). If they are consistent, the transaction execution results can be stored in their respective local ledgers and the execution results are returned to the resource client.

[0081] Among them, in different business scenarios, digital resources can include resources (or assets) associated with specific transaction businesses. The embodiments of the present application do not limit the types of digital resources.

[0082] For example, in a business scenario related to blockchain electronic bills, the transaction business can include bill business and bill derivative businesses associated with the bill business. Correspondingly, digital resources can include electronic bills involved in the bill business or bill derivative businesses or partially authorized and visible bill information in the electronic bill. Optionally, when the above blockchain network 100 is used as the blockchain network in a blockchain electronic bill system, the blockchain nodes in the blockchain network (for example, it can be Figure 1 the shown node 100d) can be used to provide bill services. The bill services here can include but are not limited to services related to electronic bill issuance, electronic bill circulation, electronic bill red-inking, electronic bill archiving, etc.; or, the blockchain nodes in the blockchain network (for example, it can be Figure 1 the shown node 100d) can be used to provide bill derivative businesses associated with the foregoing bill businesses, such as credit services, import and export services, enterprise qualification services, credit investigation services, credit purchase services, tax refund services, lottery services, etc.

[0083] Another example is that in a business scenario related to blockchain electronic files, the transaction business can include file business and file derivative businesses associated with the file business. Correspondingly, digital resources can include electronic files involved in the file business or file derivative businesses or partially authorized and visible file information in the electronic file (such as certificate information in an electronic certificate). Optionally, when the above blockchain network 100 is used as the blockchain network in a blockchain electronic file system, the blockchain nodes in the blockchain network (for example, it can be Figure 1 the shown node 100d) can be used to provide file services. The file services here can include but are not limited to services related to electronic file issuance, electronic file circulation, electronic file correction, electronic file archiving, etc.; or, the blockchain nodes in the blockchain network (for example, it can be Figure 1The node 100d) shown can be used to provide file derivative services associated with the aforementioned document services. For example, institutional cooperation services, enterprise qualification services, prescription statistics services, qualification review services, government affairs management services, etc. Among them, electronic documents can include, but are not limited to, various forms of documents such as electronic contracts, electronic official documents, electronic prescriptions, and electronic certificates.

[0084] It can be understood that the aforementioned digital resources can be transferred between the accounts of different entity objects. In the embodiments of the present application, the entity object (such as an individual user, an enterprise user, an institution, etc.) that transfers the specified digital resources through the resource client can be referred to as the first service object (such as user A1). Among them, the resource client can include, but is not limited to: an independent client, a small program running as a subroutine in the client, and a web application or extension program opened through a browser, etc. The embodiments of the present application do not limit the type of the resource client. Correspondingly, the entity object (such as an individual user, an enterprise user, an institution, etc.) that receives the digital resources transferred by the first service object can be referred to as the second service object (such as user A2). For the convenience of distinction, the digital resources specified by the first service object to be transferred to the second service object can be referred to as service resources. The service resources can include any one or more of digital resources such as electronic bills, partially authorized visible bill information in the electronic bill, electronic documents, and partially authorized visible document information in the electronic document, and there is no limitation here. Among them, the transaction initiated by the first service object through the resource client for transferring the service resources to the second service object can be referred to as a resource transfer transaction.

[0085] It can be understood that before transferring the service resources, in order to ensure the security of the service resource transfer, the specified approval object can conduct transaction approval on the resource transfer transaction, and only after the approval is passed can the service resources be transferred to the second service object. Here, the approval object refers to the entity object (such as an individual user, an enterprise user, an institution, etc.) that conducts transaction approval on the resource transfer transaction. The number of approval objects can be one or more, and there is no limitation on the number of approval objects here. Optionally, the first service object can also be used as an approval object. Among them, the terminal device associated with the approval object can be referred to as the approval terminal, that is, each approval object can conduct transaction approval on the resource transfer transaction sent by the resource client through the approval terminal held by it. Optionally, if the approval object agrees to the resource transfer transaction, the approval terminal can conduct transaction signature on the resource transfer transaction through the private key information of the approval object. Among them, the private key information and the corresponding public key information of the approval object can be configured and managed by the approval terminal.

[0086] It can be understood that, in order to overcome the problem of untrustworthiness in the off-chain approval process, embodiments of the present application can place the approval process of resource transfer transactions in a trusted execution environment off-chain, and the trusted execution environment ensures the correctness and immutability of the approval logic. For ease of distinction, embodiments of the present application can refer to the client for executing the approval logic as the approval client, which refers to an application program running in the trusted execution environment and can be used to verify whether a resource transfer transaction passes the approval.

[0087] It should be noted that the approval client can run on a terminal device or a server, and there is no limitation here. Optionally, when the approval client runs on a terminal device, this terminal device and the terminal device where the aforementioned resource client is located (i.e., the service terminal) can be the same terminal device, or different terminal devices. Or, this terminal device and any of the aforementioned approval terminals can be the same terminal device, or different terminal devices; Optionally, when the approval client runs on a server, this server can be the background server corresponding to the resource client. Embodiments of the present application do not limit the deployment methods of the approval client, the resource client, and the approval terminal.

[0088] Among them, the Trusted Execution Environment (TEE) is a hardware-based computing solution that constructs a secure area in the CPU (Central Processing Unit) through software and hardware methods to ensure the confidentiality and integrity of the programs (such as the aforementioned approval client) and data loaded therein. The TEE divides the system's hardware resources and software resources into two execution environments - the trusted part and the untrusted part (i.e., the ordinary part). These two environments are isolated, and the untrusted part cannot access the storage and memory of the trusted part. It can be understood that the TEE is a "region" separately divided at the chip level. This region does not necessarily occupy the physical location of the chip. Perhaps it only logically occupies a certain execution space. This region is responsible for providing a more secure place for the execution of code and the storage of data to ensure its confidentiality and immutability. In the absence of TEE, when the chip executes code, the code is either stored in the internal cache of the chip or in the "memory" or hard disk outside the chip. However, whether in the cache or memory, all code and execution processes can be read by other programs, which results in the lack of privacy in code execution, which is quite fatal for some applications that need to hide code and code processes. The TEE provides an independent area for code execution at the chip level, and this independent area cannot be obtained by other programs from the software and hardware levels, thereby ensuring the confidentiality and security of the code executed in this area. This code execution area of the TEE that is not affected by the outside world places sensitive information (such as payment passwords) into the TEE, and the verification of payment passwords is carried out through the interface provided by the TEE. As long as the data inside the TEE is not overwritten or the chip containing the TEE is not lost, the TEE can always provide the verification of payment passwords, while the payment passwords can hardly be obtained by external programs. On the other hand, the TEE also regularly provides data integrity proofs through the API (Application Programming Interface) interface to ensure that the external environment can know that the values stored inside the TEE have not changed.

[0089] It can be understood that the trusted execution environment solutions may include the Intel SGX (Software Guard Extensions) solution, the ARM TrustZone solution, the AMD SEV (Secure Encrypted Virtualization) solution, etc. Among them, the Intel SGX solution is a relatively mature trusted execution environment solution proposed by Intel and can support the trusted execution environment on specific models of CPUs produced by Intel. In SGX, the TEE environment for executing program code is called an Enclave. For example, the aforementioned approval client can be an Enclave program. The data in the Enclave is protected by the CPU hardware, ensuring its confidentiality and integrity. Data can be stored in the Enclave, and the stored data is encrypted by the private key of the trusted execution environment hardware key. Here, the trusted execution environment hardware key refers to the hardware key burned into the CPU by Intel during CPU production. Its private key cannot be exported under any circumstances, and its public key can be exported in specific usage scenarios.

[0090] As can be seen from the foregoing, the approval client runs in a trusted execution environment. Here, the trusted execution environment can be the trusted execution environment provided by any of the aforementioned trusted execution environment solutions or other unlisted trusted execution environment solutions. The embodiments of the present application do not make any limitations in this regard. For example, a trusted execution environment based on the aforementioned Intel SGX solution can be adopted. The trusted execution environment can be configured with one or more pairs of key information (which can be abbreviated as keys). Here, the number of keys configured for the trusted execution environment is not limited. Among them, each pair of key information can include a private key information and a public key information corresponding to the private key information. Here, the key information can be the original key information of the trusted execution environment (such as the trusted execution environment hardware key provided by Intel as mentioned above). Optionally, it can also be the key information generated later in the trusted execution environment. For example, the key management tool in the trusted execution environment can randomly generate multiple different private key information and public key information. Here, the sources of the private key information and public key information configured for the trusted execution environment are not limited. Among them, the key management tool can be integrated into the aforementioned approval client, or the key management tool can also be an application program running independently of the approval client in the trusted execution environment.

[0091] In the embodiment of the present application, the approval client running in the trusted execution environment can obtain multi-signature information associated with the approval object; wherein, the multi-signature information includes the approval signature information obtained after the approval terminal approves the resource transfer transaction; the approval signature information is obtained after the approval terminal signs the resource transfer transaction with the private key information of the approval object; the resource transfer transaction refers to a transaction initiated by the first business object through the resource client for transferring business resources to the second business object; further, the public key information of the approval object can be obtained from the trusted execution environment, and the approval signature information is verified by the public key information of the approval object. When the signature verification is successful, the approval status of the resource transfer transaction is configured as the approved status, and the resource transfer transaction in the approved status is signed with the environment private key information configured by the trusted execution environment to obtain the first transaction signature information; furthermore, the first transaction signature information can be sent to the resource client so that the resource client signs the resource transfer transaction with the private key information of the first business object to obtain the second transaction signature information, and the signed resource transfer transaction corresponding to the resource transfer transaction is determined based on the first transaction signature information and the second transaction signature information, and the signed resource transfer transaction is sent to the blockchain node in the blockchain network; wherein, the signed resource transfer transaction here can be used to instruct the blockchain node to verify the signatures of the first transaction signature information and the second transaction signature information with the environment public key information corresponding to the environment private key information and the public key information of the first business object, and when the signature verification is successful, transfer the business resources from the account address of the first business object to the account address of the second business object.

[0092] Wherein, the aforementioned environment private key information can be any private key information configured by the trusted execution environment. Correspondingly, the environment public key information can be any public key information configured by the trusted execution environment, and the environment public key information is the public key information corresponding to the environment private key information. The environment private key information and the environment public key information here can be the original key information of the trusted execution environment, or can also be any pair of key information generated by the key management tool in the trusted execution environment, for example, can be the key information generated by the key management tool for the resource transfer transaction, which is not limited here.

[0093] Among them, the aforementioned resource client can also be used to configure and store the account address and key information of the first service object. An account address can be used to uniquely identify an entity object on the blockchain. For example, the account address of the first service object can be used to uniquely identify the first service object. Among them, the key information of the first service object may include the private key information of the first service object and the corresponding public key information. Holding the private key information of the first service object can use the corresponding resource client. Therefore, the private key information needs to be carefully saved. Optionally, the corresponding public key information and account address can be generated through the private key information of the first service object.

[0094] It can be seen that the embodiment of the present application can place the approval process of resource transfer transactions in a trusted execution environment off the chain, solving the untrusted problem brought by off-chain approval, thereby improving the reliability of the off-chain approval process. After the resource transfer transaction is approved, only the signature result of the resource transfer transaction (i.e., the first transaction signature information) with the built-in private key of the trusted execution environment (i.e., the environment private key information) attached needs to be submitted to the smart contract on the chain (i.e., the resource business contract) for processing. After the contract verifies the signature successfully through the public key corresponding to the built-in private key of the trusted execution environment (i.e., the environment public key information), the resource transfer can be carried out, thereby improving the security of the transaction on the chain, and the resource transfer can be achieved through one transaction (i.e., the signed resource transfer transaction) without submitting additional transactions, greatly reducing the approval overhead.

[0095] For ease of understanding, further, please refer to Figure 2a - Figure 2b , Figure 2a - Figure 2b which is a schematic diagram of a data processing scenario based on a trusted execution environment provided by the embodiment of the present application. As Figure 2a shown, the user 21a can be used as the aforementioned first service object, the client 21b associated with the user 21a can be used as the aforementioned resource client, and the terminal device 21 where the client 21b is located can be used as the aforementioned service terminal. As Figure 2a shown, the trusted execution environment 22a can be used as the aforementioned trusted execution environment, and the client 22b running in the trusted execution environment 22a can be used as the aforementioned approval client. As Figure 2b shown, the user 23a can be used as the aforementioned second service object. As Figure 2b shown, the blockchain network 20 can be used as the aforementioned blockchain network, and multiple blockchain nodes can be deployed in the blockchain network 20. For example, the multiple blockchain nodes here can specifically include nodes 20a, 20b, 20c, and 20d, and these multiple blockchain nodes can be used to jointly maintain the blockchain 20e.

[0096] As Figure 2aAs shown, when user 21a hopes to transfer a specified digital resource (such as resource 21c) from his own account to user 23a's account, he can initiate a corresponding transaction (such as transaction 21d) through client 21b to request the blockchain node to transfer the resource. Among them, resource 21c can be used as the aforementioned business resource, and transaction 21d can be used as the aforementioned resource transfer transaction. The resource 21c can be any type of digital resource (such as electronic bills, electronic files, etc.). The type of resource 21c is not restricted here. Transaction 21d can be used to instruct user 21a to transfer resource 21c to user 23a.

[0097] It can be understood that, as Figure 2a shown, before sending transaction 21d to the blockchain node (such as node 20a) in blockchain network 20, user 21a can send transaction 21d to multiple relevant approvers through client 21b for transaction approval. The number of multiple approvers is not restricted here. For example, the multiple approvers can specifically include approver U1, approver U2, approver U3, and approver U4. Among them, approvers U1 to U4 can all be used as the aforementioned approval objects and can be specified according to business requirements. For example, when user 21a is an employee in a certain enterprise, the approvers required for him to initiate a transfer (such as paying salaries to other employees) can be specified as the finance minister, deputy general manager, general manager, etc. in the enterprise. Each approver can hold a terminal device so that they can approve the received transaction (such as the aforementioned transaction 21d) through their respective held terminal devices. For example, approver U1 holds terminal C1, approver U2 holds terminal C2, approver U3 holds terminal C3, and approver U4 holds terminal C4. The terminals C1 to C4 here can all be used as the aforementioned approval terminals.

[0098] Among them, if the approver agrees to the transaction 21d initiated by user 21a, he can sign the transaction 21d with his private key information; conversely, if the approver does not agree to the transaction 21d initiated by user 21a, he will not sign the transaction 21d. For example, as Figure 2aAs shown in the figure, assume that the approver U1 indicates agreement to Transaction 21d. Then, the terminal C1 associated with the approver U1 can perform a transaction signature on Transaction 21d using the private key information B1 of the approver U1 to obtain the signature information S1. Similarly, assume that the approver U2 indicates agreement to Transaction 21d. Then, the terminal C2 associated with the approver U2 can perform a transaction signature on Transaction 21d using the private key information B2 of the approver U2 to obtain the signature information S2. Assume that the approver U3 indicates agreement to Transaction 21d. Then, the terminal C3 associated with the approver U3 can perform a transaction signature on Transaction 21d using the private key information B3 of the approver U3 to obtain the signature information S3. Assume that the approver U4 indicates disagreement to Transaction 21d. Then, the terminal C4 associated with the approver U4 does not need to perform a transaction signature on Transaction 21d using the private key information B4 of the approver U4 and will not obtain the corresponding signature information. Among them, the signature information S1 to the signature information S3 can all be used as the approval signature information obtained after the approval terminal approves the resource transfer transaction. The signature information S composed of the signature information S1 to the signature information S3 can be used as the aforementioned multi-signature information (i.e., the signature information set composed of the approval signature information).

[0099] It can be understood that in order to be able to verify the approval signature information in the trusted execution environment, the public key information corresponding to the private key information of each approver can be pre-imported into the trusted execution environment so that the approval client can use the public key information of these approvers to verify the corresponding approval signature information, thereby determining whether the transaction passes the approval. For example, as Figure 2aAs shown, when the client 22b obtains the signature information S, since the signature information S contains the signature information S1 to the signature information S3, the public key information D1 of the approver U1, the public key information D2 of the approver U2, and the public key information D3 of the approver U3 can be obtained from the trusted execution environment 22a. Furthermore, the client 22b can perform signature verification on the signature information S1 through the public key information D1, perform signature verification on the signature information S2 through the public key information D2, and perform signature verification on the signature information S3 through the public key information D3 to obtain the approval verification results corresponding to these 3 signature information. Based on the number of successful verification results included in the approval verification results (i.e., the number of approvers who agree to the foregoing transaction 21d, which can be understood as the number of votes in favor of the transaction 21d), it can be determined whether the signature verification is successful or failed this time. Among them, the client 22b can pre-configure the approval passing condition. When the number of successful verification results meets the approval passing condition, it can be determined that the signature verification is successful. The content of the approval passing condition is not limited in the embodiments of the present application. For example, assuming that the approval passing condition indicates that a transaction can pass the approval only when all approvers agree to a transaction, then when the approval verification results corresponding to the foregoing signature information S1, the approval verification results corresponding to the signature information S2, and the approval verification results corresponding to the signature information S3 are all successful verification results (i.e., the signature information S1 to the signature information S2 are all successfully verified), it can be determined that the signature verification is successful. At this time, the client 22b can configure the approval status of the transaction 21d to the approval passed status, and can perform transaction signing on the transaction 21d in the approval passed status through the private key information 22c configured by the trusted execution environment 22a to obtain the signature information 22d corresponding to the transaction 21d. Furthermore, the signature information 22d can be sent to the client 21b. Among them, the private key information 22c here can be used as the foregoing environment private key information, and the signature information 22d can be used as the foregoing first transaction signature information.

[0100] As Figure 2bAs shown, after the client 21b receives the signature information 22d, it can perform a transaction signature on the transaction 21d through the private key information 21e of the user 21a to obtain the signature information 21f. At this time, the private key information 21e can be used as the private key information of the aforementioned first business object, and the signature information 21f can be used as the aforementioned second transaction signature information. Subsequently, the client 21b can determine the signed transaction 21g based on the signature information 22d and the signature information 21f. The signed transaction 21g can be used as the aforementioned signed resource transfer transaction, and then the signed transaction 21g can be sent to any blockchain node (such as node 20a) in the blockchain network 20. The blockchain node that receives the signed transaction 21g can broadcast the signed transaction 21g to other blockchain nodes (such as node 20b, node 20c, node 20d). In this way, each blockchain node in the blockchain network 20 can perform signature verification on the signature information 22d and the signature information 21f through the public key information 20f and the public key information 20g. The public key information 20f here can be used as the environmental public key information corresponding to the aforementioned environmental private key information, and the public key information 20g can be used as the public key information of the aforementioned first business object.

[0101] As Figure 2b shown, taking the node 20a as an example, the node 20a can perform signature verification on the signature information 21f through the public key information 20g. And when the signature verification is successful, it can obtain the public key information 20f from the resource business contract (such as business contract E, not shown in the figure) deployed on the blockchain 20e. The business contract E can be a smart contract associated with the client 21b. The client 21b can be a resource client implemented through the business contract E. The business contract E can be used to implement resource transfer and some verification logics before and after the resource transfer. The specific content of the business contract E is not limited here. Further, the node 20a can perform signature verification on the signature information 22d through the public key information 20f. And when the signature verification is successful, it can transfer the resource 21c from the account address 21h of the user 21a to the account address 23b of the user 23a through the business contract E, that is, the resource transfer is realized. The account address 21h here can be used as the account address of the aforementioned first business object, and the account address 23b can be used as the account address of the aforementioned second business object.

[0102] Optionally, when the signature information 22d or the signature information 21f fails the verification, the client 22b can configure the approval status of the transaction 21d to the unapproved status, and can send a transfer failure prompt message to the client 21b based on the unapproved status.

[0103] It is understandable that in the specific embodiments of the present application, data such as private key information, public key information, and signature information of certain entity objects (such as the aforementioned approval object, the first business object) are involved. When the embodiments in the present application are applied to specific products or technologies, the permission or consent of the entity object needs to be obtained, and the collection, use, and processing of relevant data need to comply with relevant regulations and standards in the relevant region. For example, a prompt interface or a pop-up window can be displayed, which is used to prompt the entity object that private key information, public key information, signature information, etc. are currently being collected. Only after obtaining the confirmation operation of the entity object on the prompt interface or the pop-up window, the relevant steps of data acquisition are started, otherwise it ends.

[0104] It should be noted that the method provided by the embodiments of the present application is applicable to various application scenarios with transaction approval requirements, involving fields such as finance, payment, gaming, and office. It can ensure the security and credibility of the approval process through a trusted execution environment, and can save approval costs.

[0105] Further, please refer to Figure 3 , Figure 3 which is a schematic flowchart of a data processing method based on a trusted execution environment provided by the embodiments of the present application. Figure 1 As Figure 3 shown, this method can be executed by an approval client, and the approval client runs in a trusted execution environment. This method can specifically include the following steps S101 - step S103.

[0106] Step S101, obtain multi-signature information associated with the approval object;

[0107] It can be understood that before the resource client sends a resource transfer transaction to the blockchain node, the approval client can obtain multi-signature information associated with the approval object. Here, the multi-signature information can include approval signature information obtained after the approval terminal approves the resource transfer transaction; the approval signature information is obtained after the approval terminal signs the resource transfer transaction with the private key information of the approval object; the resource transfer transaction refers to a transaction initiated by the first business object through the resource client and used to transfer business resources to the second business object. Here, the type of business resources is not limited.

[0108] Among them, the number of all approval objects for transaction approval of resource transfer transactions (i.e., the total number of approval objects) can be one or more, and the number of approval objects is not limited here. When conducting transaction approval for resource transfer transactions, if a certain approval object agrees to the resource transfer transaction, the corresponding approval terminal can use the private key information of the approval object to sign the resource transfer transaction to obtain the corresponding approval signature information. That is to say, the approval object indicates its agreement to the resource transfer transaction by signing the resource transfer transaction. Therefore, when all approval objects have signed the resource transfer transaction, one or more approval signature information can be obtained, and the number of approval signature information is less than or equal to the total number of approval objects. The number of approval signature information is not limited here.

[0109] Among them, the multi-signature information can be understood as a set obtained by aggregating the aforementioned one or more approval signature information off-chain. For example, please continue to refer to the above Figure 2a , the signature information S can be used as the multi-signature information. The signature information S can specifically include the signature information S1 of approver U1, the signature information S2 of approver U2, and the signature information S3 of approver U3. Among them, optionally, any one of the approval terminals can aggregate one or more approval signature information collected to obtain multi-signature information containing the one or more approval signature information, and send the multi-signature information to the approval client for signature verification; alternatively, optionally, an aggregation device associated with the approval client can aggregate one or more approval signature information collected to obtain multi-signature information containing the one or more approval signature information, and send the multi-signature information to the approval client for signature verification. Here, the aggregation device can be a terminal device or a server providing an aggregation service, and the form of the aggregation device is not limited here.

[0110] For ease of understanding, please refer to Figure 4 , Figure 4 is a schematic diagram of an off-chain approval scenario based on a trusted execution environment provided by an embodiment of the present application. As Figure 4As shown, an application program 40b runs in the trusted execution environment 40a. This application program 40b (which can also be called an approval program or approval application) can serve as the aforementioned approval client for executing specific approval logics. Suppose user X1 (which can be the aforementioned first business object) initiates a transaction Y1 corresponding to a transfer request (which can be the aforementioned resource transfer transaction). Then, the designated M approvers (which can be the aforementioned approval objects, where M is a positive integer) can each conduct transaction approvals for this transaction Y1. The M approvers specifically can include approver 1, approver 2, …, approver M. If a certain approver agrees to this transfer request, they can use their private key information to conduct a transaction signature for this transaction Y1. Conversely, if a certain approver disagrees with this transfer request, there is no need to conduct a transaction signature for this transaction Y1. Further, the approval results of each approver can be aggregated off-chain. Specifically, any approver's approval terminal can collect all the approval signature information and aggregate it into multi-signature information, or relevant aggregation devices can collect all the approval signature information and aggregate it into multi-signature information. There is no limitation on the method of obtaining the multi-signature information here. The obtained multi-signature information is sent to the approval logic inside the trusted execution environment 40a for verification.

[0111] Step S102: Obtain the public key information of the approval object from the trusted execution environment, conduct signature verification on the approval signature information through the public key information of the approval object, and when the signature verification is successful, configure the approval status of the resource transfer transaction as the approved status. Through the environment private key information configured by the trusted execution environment, conduct a transaction signature on the resource transfer transaction in the approved status to obtain the first transaction signature information.

[0112] It can be understood that in order to implement signature verification on each approval signature information in the aforementioned multi-signature information, embodiments of this application can import the public key information of each approval object into the trusted execution environment so that the approval logic in the trusted execution environment can use these public key information to separately verify the approval signature information of the corresponding approval objects. Based on this, the approval client can obtain the public key information of the approval object from the trusted execution environment, conduct signature verification on the approval signature information through the public key information of the approval object, and when the signature verification is successful, can configure the approval status of the resource transfer transaction as the approved status. This approved status is used to indicate that the resource transfer transaction has passed the approval. Furthermore, through the environment private key information configured by the trusted execution environment, conduct a transaction signature on the resource transfer transaction in this approved status to obtain the first transaction signature information.

[0113] It can be understood that whether the resource transfer transaction passes the approval can be determined by the number of approved signature information with successful signature verification (that is, the number of approval objects indicating consent to the resource transfer transaction, or the number of votes in favor of the resource transfer transaction). In practical applications, relevant business parties can configure corresponding approval passing conditions in the approval logic according to business needs. When the number of approved signature information with successful signature verification meets the approval passing conditions, it can be considered that the resource transfer transaction truly passes the approval. The specific content of the approval passing conditions is not restricted here. For example, the approval passing condition can be set that when all relevant approval objects indicate consent to the resource transfer transaction (that is, the number of approved signature information with successful signature verification is equal to the total number of approval objects), it is determined that the resource transfer transaction passes the approval; for another example, the approval passing condition can set a threshold for the number of approvals required for the resource transfer transaction to pass the approval. When the number of approved signature information with successful signature verification is greater than or equal to the approval number threshold, it is determined that the resource transfer transaction passes the approval.

[0114] Specifically, assume that the above multi-signature information includes the approval signature information of M approval objects (such as the approver 1, approver 2,..., approver M shown above) Figure 4 ; M is a positive integer; then the specific process of signature verification of the approval signature information through the public key information of the approval objects can be as follows: Obtain the public key information of M approval objects from the trusted execution environment, and perform signature verification on the approval signature information of M approval objects through the public key information of these M approval objects, and M approval verification results corresponding to the approval signature information can be obtained; the approval verification results here can include the verification success result or verification failure result corresponding to each approval signature information in the M approval signature information; when the number of verification success results in the approval verification results (that is, the number of approved signature information with successful signature verification) meets the approval passing conditions configured by the approval client, it can be determined that the signature verification is successful.

[0115] For example, please refer to the above again Figure 2a , such as Figure 2aAs shown, assuming M = 3, the multi-signature information specifically includes the signature information S1 of approver U1, the signature information S2 of approver U2, and the signature information S2 of approver U2. The signature information S1 is verified for signature through the public key information D1 of approver U1. Optionally, when the signature verification of signature information S1 is successful, the verification result 1 corresponding to the signature information S1 can be obtained as a successful signature verification result. Conversely, optionally, when the signature verification of signature information S1 fails, the verification result 1 corresponding to the signature information S1 can be obtained as a failed signature verification result. Similarly, the signature information S2 is verified for signature through the public key information D2 of approver U2, and the verification result 2 corresponding to the signature information S2 can be obtained as a successful signature verification result or a failed signature verification result; the signature information S3 is verified for signature through the public key information D3 of approver U3, and the verification result 3 corresponding to the signature information S3 can be obtained as a successful signature verification result or a failed signature verification result. At this time, the verification result 1, the verification result 2, and the verification result 3 can be used as the aforementioned approval signature verification results.

[0116] Among them, optionally, the approval passing condition may include an approval quantity threshold, which is used to indicate the minimum quantity of successful signature verification results required for the resource transfer transaction to pass the approval. No specific limit is imposed on the specific value of the approval quantity threshold here. Based on this, when the quantity of successful signature verification results in the aforementioned approval signature verification results is greater than or equal to the approval quantity threshold, it can be determined that the signature verification is successful. For example, still taking the aforementioned Figure 2a as an example, assuming the approval quantity threshold is set to 2, and the verification result 1, the verification result 2, and the verification result 3 are all successful signature verification results, that is, the quantity of successful signature verification results in the approval signature verification results is 3, which is already greater than the set approval quantity threshold, then it can be determined that the signature verification is successful at this time.

[0117] Optionally, the approval passing condition may include an approval ratio threshold, which is used to indicate the minimum ratio between the quantity of successful signature verification results required for the resource transfer transaction to pass the approval and the total number of approval objects. No specific limit is imposed on the specific value of the approval ratio threshold here. Based on this, the signature verification success ratio between the quantity of successful signature verification results in the approval signature verification results and the total number of approval objects can be obtained; the total number of approval objects here is a positive integer greater than or equal to the aforementioned M; when the signature verification success ratio is greater than or equal to the approval ratio threshold, it can be determined that the signature verification is successful. For example, still taking the aforementioned Figure 2a as an example, assuming the approval ratio threshold is set to 50%, and the verification result 1, the verification result 2, and the verification result 3 are all successful signature verification results, that is, the quantity of successful signature verification results in the approval signature verification results is 3, and the total number of approval objects is 4. It can be calculated that the signature verification success ratio at this time is 3 / 4, which is already greater than the set approval ratio threshold, then it can be determined that the signature verification is successful at this time.

[0118] In addition, other settings can be made for the approval passing conditions, which will not be listed one by one here.

[0119] It can be understood that when the above-mentioned approval signature information is verified successfully, it means that the resource transfer transaction has passed the approval of the approval object. Therefore, the approval status of the resource transfer transaction can be configured as the approval passed status. And after determining that the resource transfer transaction has passed the approval, the resource transfer transaction in the approval passed status can be transaction-signed by the environment private key information configured in the trusted execution environment, and the signature result (i.e., the first transaction signature information) can be output, indicating that the off-chain approval process of the resource transfer transaction has been verified by the trusted execution environment, and the trusted execution environment ensures the reliability of the approval process. Subsequently, when the resource transfer transaction is submitted to the chain, if it is verified that the first transaction signature information is signed by the trusted execution environment, the resource transfer transaction can be regarded as a valid transaction, and thus the resource transfer logic can be executed. For example, please continue to refer to the above Figure 4 , in combination with the foregoing, the trusted execution environment 40a has a built-in pair of keys (including the exportable public key 40c and the non-exportable private key 40d). When the application 40b verifies that the transaction Y1 has passed the approval through the approval logic, the private key 40d (which can be used as the aforementioned environment private key information) in the trusted execution environment 40a can be used to transaction-sign the transaction Y1 to obtain the signature 40e (which can be used as the aforementioned first transaction signature information). Subsequently, after the user X1 submits the transaction Y1 to the chain, the blockchain node can verify the signature 40e through the exportable public key 40c (which can be used as the aforementioned environment public key information) to determine whether the corresponding transfer request is valid.

[0120] Among them, the environment private key information and the corresponding environment public key information here can be the original key information of the trusted execution environment (such as the trusted execution environment hardware key provided by Intel as mentioned above), or can be the key information generated by the key management tool in the trusted execution environment. The embodiments of the present application do not limit this. Optionally, the key management tool can generate a pair of key information for the resource transfer transaction, where the private key information can be used as the aforementioned environment private key information, and the public key information can be used as the aforementioned environment public key information. Or, optionally, the key management tool can pre-generate multiple pairs of key information. When it is determined that the resource transfer transaction has passed the approval, any pair of key information can be randomly selected from these multiple pairs of key information. The private key information in the selected key information can be used as the aforementioned environment private key information, and the public key information of the selected key information can be used as the aforementioned environment public key information. It can be understood that for different transactions, the trusted execution environment can use the same private key information to sign them, such as using the same private key information to sign all transactions; or, it can also use different private key information to sign them, which is not limited here.

[0121] Optionally, the trusted execution environment may present a valid remote attestation of the environmental private key information it uses. For ease of distinction, this remote attestation may be referred to as the fourth remote attestation. Any entity object (such as the first service object, the approval object, the second service object, or other objects not listed) may send this fourth remote attestation to the remote authentication server for remote authentication. Successful remote authentication indicates that the currently used environmental private key information is valid, secure, and trustworthy. Specifically, the approval client may obtain the fourth service information associated with the environmental private key information, the program measurement value of the approval client, and the environmental parameter information associated with the trusted execution environment, and may sign the fourth service information, the program measurement value, and the environmental parameter information using the environmental private key information to obtain the fourth proof signature information. Furthermore, based on the fourth service information, the program measurement value, the environmental parameter information, and the fourth proof signature information, the fourth remote attestation corresponding to the environmental private key information may be determined. For example, according to a specified proof format, the fourth service information, the program measurement value, the environmental parameter information, and the fourth proof signature information may be recombined into the fourth remote attestation.

[0122] Among them, the fourth service information may be any information associated with the environmental private key information, which may be agreed upon by the entity object requesting the presentation of the fourth remote attestation and the approval client, that is, a piece of information specified by the entity object may be brought in as a challenge, so that the entity object can know that the obtained fourth remote attestation is generated for this challenge. For example, the fourth service information may be the environmental public key information corresponding to the environmental private key information, or may be a randomly generated string for the environmental private key information, etc. The specific content of the fourth service information in the embodiments of the present application is not limited. The program measurement value of the approval client is the measurement value / summary of the application program corresponding to the approval client (such as the aforementioned application program 40b) (such as the measurement value of the Enclave program), which may be determined according to the binary code (or binary file) of the application program and some of its initialization parameters. In the trusted execution environment, the measurement value of each application program is unique, and any change to the application program will cause its measurement value to change. Therefore, if an application program is not changed in the trusted execution environment, its measurement value will not change. The environmental parameter information associated with the trusted execution environment (such as the Enclave program publisher information) may include, but is not limited to, some relevant parameters inside the trusted execution environment such as the current version information of the trusted execution environment and the unique serial number of the trusted execution environment. If the trusted execution environment has not changed, the environmental parameter information will not change.

[0123] Among them, the specific process of signing the fourth service information, program measurement value, and environment parameter information with the environment private key information to obtain the fourth proof signature information can be as follows: concatenate the fourth service information, program measurement value, and environment parameter information to obtain the fourth concatenated data; sign the fourth concatenated data with the environment private key information to obtain the fourth proof signature information. Optionally, in addition to the fourth service information, program measurement value, and environment parameter information, other key information can also be concatenated and signed together to obtain the fourth proof signature information, which is not limited in the embodiments of the present application.

[0124] In addition, it can be understood that in addition to the fourth service information, program measurement value, environment parameter information, and fourth proof signature information, the fourth remote proof may also include other key information, which will not be listed one by one here.

[0125] Among them, after obtaining the fourth remote proof, the above-mentioned entity object (such as the first service object) can send the fourth remote proof to the remote authentication server for remote authentication. For example, it can send the fourth remote authentication request with the fourth remote proof to the remote authentication server (such as the authentication server provided by Intel), so that the remote authentication server can perform signature verification on the fourth proof signature information in the fourth remote proof through the environment public key information, and can verify other key information to be verified when the signature verification is successful, and finally obtain the fourth authentication verification report. If the fourth authentication verification report indicates successful remote authentication, it can be determined that the currently used environment private key information is valid, secure, and trustworthy.

[0126] Step S103, send the first transaction signature information to the resource client.

[0127] It can be understood that after obtaining the first transaction signature information, the approval client can send the first transaction signature information to the resource client, so that the resource client can perform transaction signing on the resource transfer transaction through the private key information of the first business object to obtain the second transaction signature information, and can determine the signed resource transfer transaction corresponding to the resource transfer transaction based on the first transaction signature information and the second transaction signature information, and send the signed resource transfer transaction to the blockchain node in the blockchain network. Among them, the resource client can add the first transaction signature information to the resource transfer transaction (for example, use the first transaction signature information as a field in the resource transfer transaction), perform transaction signing on the resource transfer transaction added with the first transaction signature information through the private key information of the first business object to obtain the second transaction signature information, and then can reorganize the second transaction signature information and the resource transfer transaction added with the first transaction signature information into a signed resource transfer transaction. At this time, both the first transaction signature information and the second transaction signature information can be used as a field in the signed resource transfer transaction. In this way, the approval client only needs to transmit the first transaction signature information to the resource client, which can save the data transmission bandwidth between the two; optionally, the approval client can add the first transaction signature information to the resource transfer transaction (for example, use the first transaction signature information as a field in the resource transfer transaction), and then send the resource transfer transaction added with the first transaction signature information to the resource client, so that the resource client can perform transaction signing on the resource transfer transaction added with the first transaction signature information through the private key information of the first business object, so as to obtain the second transaction signature information. In this way, the approval client can directly transmit the resource transfer transaction that has been confirmed to pass the approval to the resource client, improving the credibility of the approval result corresponding to the resource transfer transaction.

[0128] Among them, the foregoing signed resource transfer transaction can be used to instruct the blockchain node to perform signature verification on the first transaction signature information and the second transaction signature information through the environmental public key information corresponding to the environmental private key information and the public key information of the first business object, and when the signature verification is successful, the business resources can be transferred from the account address of the first business object to the account address of the second business object. For the specific operation process executed by the blockchain node, reference can be made to the description in the subsequent Figure 9 corresponding embodiment, which will not be elaborated here.

[0129] As described above, when the resource transfer transaction passes the approval, the built-in private key of the trusted execution environment (i.e., the environment private key information) can be used to sign the resource transfer transaction, and the signature result (i.e., the first transaction signature information) is output. For the convenience of subsequent verification, the public key corresponding to the built-in private key of the trusted execution environment (i.e., the environment public key information) is recorded in the resource business contract deployed on the chain. In this way, when the signed resource transfer transaction carrying the first transaction signature information is submitted to the resource business contract, the resource business contract verifies the first transaction signature information through the recorded environment public key information. When the signature verification is successful, it can be confirmed that the first transaction signature information is signed by the trusted execution environment. At this time, the resource transfer transaction can be regarded as a valid transaction, and the resource transfer can be carried out.

[0130] It can be seen that the embodiment of the present application provides an off-chain transaction approval scheme based on a trusted execution environment. Since the approval client runs in the trusted execution environment, the correctness and immutability of the approval logic can be ensured through the trusted execution environment, solving the untrusted problem brought by off-chain approval. That is to say, placing the approval process in the trusted execution environment off-chain can improve the reliability of the off-chain approval process. When the subsequent blockchain node calls the resource business contract to verify the relevant signature information of the signed resource transfer transaction successfully, it can be confirmed that the resource transfer transaction on the chain has passed the approval, which is equivalent to the blockchain nodes jointly witnessing the approval process of the resource transfer transaction, thereby improving the security of the transaction on the chain. In addition, when performing a resource transfer, only the signature information of the resource transfer transaction by the built-in key of the trusted execution environment needs to be attached, and the transfer of relevant business resources can be achieved through one transaction, without the need for additional transactions on the chain, reducing the data storage and verification pressure on the blockchain, saving the handling fees required for approval, and thus reducing the overall approval cost.

[0131] Further, please refer to Figure 5 , Figure 5 is the second flowchart of the data processing method based on the trusted execution environment provided by the embodiment of the present application. As Figure 5 shown, this method can be executed by an approval client that runs in a trusted execution environment. This method can specifically include the following steps S201 - step S206.

[0132] Step S201, obtain multi-signature information associated with the approval object;

[0133] Step S202: Obtain the public key information of the approval object from the trusted execution environment, verify the signature of the approval signature information using the public key information of the approval object, and when the signature verification is successful, configure the approval status of the resource transfer transaction to the approved status. Use the environment private key information configured by the trusted execution environment to sign the resource transfer transaction in the approved status to obtain the first transaction signature information;

[0134] Step S203: Send the first transaction signature information to the resource client;

[0135] Among them, for the specific implementation process of the above steps S201 - S203, reference can be made to the descriptions of steps S101 - S103 in the corresponding embodiments above, and details will not be elaborated here. Figure 3 The descriptions of steps S101 - S103 in the corresponding embodiments above will not be repeated here.

[0136] Step S204: Obtain the first remote attestation corresponding to the approved status and send the first remote attestation to the resource client;

[0137] It can be understood that when the resource transfer transaction passes the approval, in addition to giving an approved result, the trusted execution environment will also present a remote attestation of the approved result, which is called the first remote attestation. This first remote attestation can be submitted to the resource business contract on the blockchain together with the signed resource transfer transaction, and the resource business contract will record the first remote attestation. That is to say, the approval client can obtain the first remote attestation corresponding to the approved status and send the first remote attestation to the resource client, so that when the resource client sends the signed resource transfer transaction to the blockchain node, the first remote attestation is sent to the blockchain node; the first remote attestation is used to be written into the resource business contract deployed on the blockchain corresponding to the blockchain network.

[0138] For ease of understanding, please also refer to Figure 6 , Figure 6 which is a schematic diagram of a scenario for obtaining the first remote attestation provided by an embodiment of the present application. As shown in Figure 6As shown, the approval logic is built into the trusted execution environment 60a, and this approval logic is executed by the application 60b running in the trusted execution environment 60a. This application 60b can serve as the aforementioned approval client. Moreover, a pair of keys is built into the trusted execution environment 60a, including an exportable public key 60c and an unexportable private key 60d. This public key 60c can serve as the aforementioned environment public key information, and this private key 60d can serve as the aforementioned environment private key information. The specific process of obtaining the first remote attestation corresponding to the approval passed status can be as follows: Obtain the first service information associated with the approval passed status, the program measurement value of the approval client (such as the measurement value / digest of the application 60b), and the environment parameter information associated with the trusted execution environment (such as the current version information, unique serial number, and other internal relevant parameters of the trusted execution environment 60a). Sign the first service information, program measurement value, and environment parameter information with the environment private key information (such as the private key 60d) to obtain the first attestation signature information. Furthermore, based on the first service information, program measurement value, environment parameter information, and the first attestation signature information, determine the first remote attestation (such as the remote attestation 60e) corresponding to the approval passed status. For example, according to the specified attestation format, reorganize the first service information, program measurement value, environment parameter information, and the first attestation signature information into the first remote attestation.

[0139] Among them, the first service information can be any information associated with the approval passed status, which can be agreed upon by the entity object (such as the first service object) requesting the presentation of the first remote attestation and the approval client, that is, a piece of information specified by this entity object can be brought in as a challenge, so that this entity object can know that the obtained first remote attestation is generated for this challenge. Or, the approval client can also specify a piece of information by itself as the first service information. For example, the first service information can be a randomly generated string for the approval passed status. The embodiments of the present application do not limit the specific content of the first service information.

[0140] Among them, the specific process of signing the first service information, program measurement value, and environment parameter information with the environment private key information to obtain the first attestation signature information can be as follows: Perform a splicing process on the first service information, program measurement value, and environment parameter information to obtain the first spliced data; Sign the first spliced data with the environment private key information to obtain the first attestation signature information. Optionally, in addition to the first service information, program measurement value, and environment parameter information, other key information can also be spliced and signed together to obtain the first attestation signature information. The embodiments of the present application do not limit this.

[0141] Such as Figure 6The remote attestation 60e shown can be used as the aforementioned first remote attestation. The remote attestation 60e mainly includes the measurement / summary of the application 60b (i.e., the aforementioned program measurement), the first business information associated with the approval passed status, the relevant parameters of the trusted execution environment 60a (i.e., the aforementioned environment parameter information), and the signature of the first three items by the private key 60d (i.e., the aforementioned first attestation signature information). In addition, it can be understood that in addition to the first business information, program measurement, environment parameter information, and first attestation signature information, the first remote attestation may also include other key information, which will not be listed one by one here.

[0142] Optionally, after the resource transfer is completed, any entity object with read permission (such as the first business object, approval object, second business object, or other unlisted objects) can obtain the first remote attestation from the resource business contract and verify it with the corresponding institution (such as Intel's authentication service). Passing the verification means that the approval result is generated by the trusted execution environment, thus ensuring the security and credibility of the approval process. For example, taking the first business object as an example, after obtaining the first remote attestation, the first business object can send the first remote attestation to the remote authentication server through the resource client for remote authentication. For example, it can send the first remote authentication request with the first remote attestation attached to the remote authentication server (such as the authentication server provided by Intel), so that the remote authentication server can verify the first attestation signature information in the first remote attestation through the environment public key information (such as the aforementioned public key 60c), and verify other key information to be verified when the signature verification is successful, and finally obtain the first authentication verification report. If the first authentication verification report indicates that the remote authentication is successful, it can be determined that the approval passed status is configured by the trusted execution environment, thus ensuring the security and credibility of the approval process.

[0143] Step S205, when receiving the attestation generation request sent by the first business object through the resource client, obtain the second remote attestation corresponding to the approval client based on the attestation generation request, and send the second remote attestation to the resource client;

[0144] It can be understood that any entity object (such as the first business object, approval object, second business object, or other unlisted objects) can request the trusted execution environment to present the remote attestation of the approval logic and verify it with the corresponding institution (such as Intel's authentication service). Passing the verification means that the approval logic is correct and not tampered with, and the approval logic runs in the trusted execution environment. Among them, presenting the remote attestation of the approval logic is an optional operation and can be used for filing records (for example, the remote attestation can be submitted to the resource business contract for recording).

[0145] For ease of understanding, here, taking the first service object as an example, when the approval client receives a proof generation request sent by the first service object through the resource client, the approval client can obtain the second remote proof corresponding to the approval client based on the proof generation request and send the second remote proof to the resource client.

[0146] For ease of understanding, please also refer to Figure 7 , Figure 7 which is a schematic diagram of a scenario for obtaining a second remote proof provided by an embodiment of the present application. As Figure 7 shown, the approval logic is built into the trusted execution environment 70a, and the approval logic is executed by the application program 70b running in the trusted execution environment 70a. The application program 70b can be used as the aforementioned approval client, and a pair of keys are built into the trusted execution environment 70a, including an exportable public key 70c and an unexportable private key 70d. The public key 70c can be used as the aforementioned environment public key information, and the private key 70d can be used as the aforementioned environment private key information. The specific process of obtaining the second remote proof corresponding to the approval client can be as follows: Obtain the program measurement value of the approval client (such as the measurement value / digest of the application program 70b) and the environment parameter information associated with the trusted execution environment (such as the current version information, unique serial number, and other internal relevant parameters of the trusted execution environment 70a) based on the proof generation request, and the second service information associated with the first service object can be obtained from the proof generation request; furthermore, the program measurement value, the second service information, and the environment parameter information can be signed by the environment private key information (such as the private key 70d) to obtain the second proof signature information; based on the program measurement value, the second service information, the environment parameter information, and the second proof signature information, determine the second remote proof corresponding to the approval client (such as the remote proof 70e). For example, according to the specified proof format, the program measurement value, the second service information, the environment parameter information, and the second proof signature information can be reorganized into the second remote proof, and the second remote proof is sent to the resource client so that the resource client can send the second remote proof to the remote authentication server for remote authentication.

[0147] Among them, the second service information can be any information associated with the first service object, which can be agreed upon by the first service object that requests to present the second remote proof and the approval client, that is, a piece of information specified by the first service object can be brought in as a challenge, so that the first service object can know that the obtained second remote proof is generated for this challenge. For example, the second service information can be a random string generated by the first service object (such as a piece of message msg). The specific content of the second service information is not limited in the embodiment of the present application.

[0148] Among them, the specific process of signing the program measurement value, the second service information, and the environment parameter information with the environment private key information to obtain the second proof signature information may be: concatenating the program measurement value, the second service information, and the environment parameter information to obtain second concatenated data; signing the second concatenated data with the environment private key information to obtain the second proof signature information. Optionally, in addition to the program measurement value, the second service information, and the environment parameter information, other key information may also be concatenated and signed together to obtain the second proof signature information, which is not limited in the embodiments of the present application.

[0149] Such as Figure 7 The remote attestation 70e shown can be used as the aforementioned second remote attestation. The remote attestation 70e mainly may include the measurement value / digest of the application program 70b (i.e., the aforementioned program measurement value), the second service information associated with the first service object, the relevant parameters of the trusted execution environment 70a (i.e., the aforementioned environment parameter information), and the signature of the first three items with the private key 70d (i.e., the aforementioned second proof signature information). In addition, it can be understood that in addition to the second service information, the program measurement value, the environment parameter information, and the second proof signature information, the second remote attestation may also include other key information, which will not be listed one by one here.

[0150] It can be understood that after obtaining the second remote attestation, the first service object can verify it with the corresponding institution (such as Intel's authentication service). Passing the verification means that the approval logic is correct and has not been tampered with, and the approval logic runs in the trusted execution environment. For example, after obtaining the second remote attestation, the first service object can send the second remote attestation to the remote authentication server through the resource client for remote authentication. For example, it can send the second remote authentication request with the second remote attestation attached to the remote authentication server (such as the authentication server provided by Intel), so that the remote authentication server verifies the second proof signature information in the second remote attestation with the environment public key information (such as the aforementioned public key 70c), and can verify other key information to be verified when the signature verification is successful, and finally obtain the second authentication verification report. If the second authentication verification report indicates that the remote authentication is successful, it can be determined that the approval logic runs in the trusted execution environment, and the approval logic is correct and has not been tampered with, thus ensuring the security and trustworthiness of the approval process.

[0151] After generating the second remote attestation, optionally, the first service object can submit the obtained second remote attestation to the resource service contract for recording through the resource client, or, optionally, the approval client can also submit the second remote attestation to the resource service contract for recording by itself.

[0152] Optionally, any external entity object (such as the aforementioned first business object) can actively request the approval client to generate a remote proof of the approval logic (such as the aforementioned second remote proof) when needed. Alternatively, optionally, the approval logic can also default to requiring the approval client to generate a remote proof of the approval logic and output the remote proof when an entity object needs it.

[0153] Step S206: When the signature verification fails, configure the approval status of the resource transfer transaction as the unapproved status, obtain the third remote proof corresponding to the unapproved status, and generate a transfer failure prompt message based on the unapproved status. Send the third remote proof and the transfer failure prompt message to the resource client.

[0154] It can be understood that when the resource transfer transaction fails to pass the approval, the trusted execution environment can output the result of the approval failure and the remote proof of the approval failure result, which is called the third remote proof. The approval client can send the third remote proof to the resource client for filing records, and can also send a transfer failure prompt message to the resource client to indicate that the resource transfer transaction fails to pass the approval and the business resources cannot be transferred from the account address of the first business object to the account address of the second business object. At this time, the approval client will not sign the resource transfer transaction through the environment private key information configured by the trusted execution environment, and the resource client cannot submit the resource transfer transaction to the chain, resulting in a failed resource transfer.

[0155] Specifically, when the signature verification fails, the approval client can configure the approval status of the resource transfer transaction as the unapproved status, which is used to indicate that the resource transfer transaction fails to pass the approval. Then, it can obtain the third remote proof corresponding to the unapproved status, and generate a transfer failure prompt message based on the unapproved status. Send the third remote proof and the transfer failure prompt message to the resource client. The specific content of the transfer failure prompt message in the embodiments of the present application is not limited.

[0156] For ease of understanding, please also refer to Figure 8 , Figure 8 which is a schematic diagram of a scenario for obtaining the third remote proof provided by the embodiments of the present application. As Figure 8As shown, the approval logic is built into the trusted execution environment 80a. The approval logic is executed by the application 80b running in the trusted execution environment 80a. The application 80b can serve as the aforementioned approval client. A pair of keys is built into the trusted execution environment 80a, including an exportable public key 80c and an unexportable private key 80d. The public key 80c can serve as the aforementioned environment public key information, and the private key 80d can serve as the aforementioned environment private key information. The specific process of obtaining the third remote attestation corresponding to the approval not passed status can be as follows: Obtain the third service information associated with the approval not passed status, the program measurement value of the approval client (such as the measurement value / digest of the application 80b), and the environment parameter information associated with the trusted execution environment (such as the current version information, unique serial number, and other internal related parameters of the trusted execution environment 80a). Sign the third service information, program measurement value, and environment parameter information with the environment private key information (such as the private key 80d) to obtain the third attestation signature information. Furthermore, based on the third service information, program measurement value, environment parameter information, and third attestation signature information, determine the third remote attestation (such as the remote attestation 80e) corresponding to the approval not passed status. For example, according to the specified attestation format, reorganize the third service information, program measurement value, environment parameter information, and third attestation signature information into the third remote attestation.

[0157] Among them, the third service information can be any information associated with the approval not passed status, which can be agreed upon by the entity object (such as the first service object) requesting the third remote attestation and the approval client, that is, a piece of information specified by the entity object can be brought in as a challenge, so that the entity object can know that the obtained third remote attestation is generated for this challenge. Or, the approval client can also specify a piece of information by itself as the third service information. For example, the third service information can be a randomly generated string for the approval not passed status. The embodiments of the present application do not limit the specific content of the third service information.

[0158] Among them, the specific process of signing the third service information, program measurement value, and environment parameter information with the environment private key information to obtain the third attestation signature information can be as follows: Concatenate the third service information, program measurement value, and environment parameter information to obtain the third concatenated data. Sign the third concatenated data with the environment private key information to obtain the third attestation signature information. Optionally, in addition to the third service information, program measurement value, and environment parameter information, other key information can also be concatenated and signed together to obtain the third attestation signature information. The embodiments of the present application do not limit this.

[0159] Such as Figure 8The remote attestation 80e shown can be used as the aforementioned third remote attestation. The remote attestation 80e mainly can include the measurement / summary of the application program 80b (i.e., the aforementioned program measurement), the third business information associated with the disapproved status, the relevant parameters of the trusted execution environment 80a (i.e., the aforementioned environment parameter information), and the signature of the first three items by the private key 80d (i.e., the aforementioned third attestation signature information). In addition, it can be understood that in addition to the third business information, program measurement, environment parameter information, and third attestation signature information, the third remote attestation can also include other key information, which will not be listed one by one here.

[0160] Optionally, when the first business object obtains the third remote attestation, it can go to the corresponding institution (such as Intel's authentication service) for verification. Passing the verification means that the result of disapproval is generated by the trusted execution environment, thus ensuring the security and trustworthiness of the approval process. For example, after the first business object obtains the third remote attestation, it can send the third remote attestation to the remote authentication server through the resource client for remote authentication. For example, it can send the third remote authentication request with the third remote attestation attached to the remote authentication server (such as the authentication server provided by Intel), so that the remote authentication server verifies the third attestation signature information in the third remote attestation through the environmental public key information (such as the aforementioned public key 80c), and when the signature verification is successful, it can verify other key information to be verified, and finally obtain the third authentication verification report. If the third authentication verification report indicates successful remote authentication, it can be determined that the disapproved status is configured by the trusted execution environment, thus ensuring the security and trustworthiness of the approval process.

[0161] Among them, there is no difference in the execution sequence among step S204, step S205, and step S206, and they can be considered as parallel steps.

[0162] It can be seen that the embodiment of the present application combines the security of the smart contract on the blockchain (such as the aforementioned resource business contract) and the trusted execution environment, and realizes an off-chain approval scheme based on the trusted execution environment. The approval process can be placed in the off-chain trusted execution environment, and the trusted execution environment ensures the correctness and immutability of the approval logic. After the resource transfer transaction passes the approval, only the execution result given by the trusted execution environment (i.e., the aforementioned first remote attestation) and the signature result of the resource transfer transaction by its built-in private key (i.e., the aforementioned first transaction signature information) need to be attached and submitted to the resource business contract on the chain for processing together with the resource transfer transaction. After the resource business contract successfully verifies the signature through the public key corresponding to the built-in private key of the trusted execution environment, it can execute the corresponding resource transfer logic, so that the resource transfer can be realized through one transaction without submitting additional transactions, greatly saving the approval cost.

[0163] Further, please refer toFigure 9 , Figure 9 is a flowchart of a data processing method based on a trusted execution environment provided by an embodiment of the present application Figure 3 . As Figure 9 shown, this method can be executed by a blockchain node in a blockchain network. The blockchain node can be any blockchain node in the blockchain network (such as a consensus node). For example, the blockchain node can be any blockchain node in the blockchain network 100 shown above Figure 1 (such as node 100a). This method can specifically include the following steps S301-S303

[0164] Step S301: Obtain a signed resource transfer transaction corresponding to a resource transfer transaction

[0165] It can be understood that the blockchain node can obtain a signed resource transfer transaction corresponding to the resource transfer transaction. Here, the resource transfer transaction refers to a transaction initiated by a first service object through a resource client for transferring service resources to a second service object; the signed resource transfer transaction is determined based on a first transaction signature information and a second transaction signature information when the resource client signs the resource transfer transaction with the private key information of the first service object to obtain the second transaction signature information; the first transaction signature information is obtained after the resource client signs the resource transfer transaction in an approved state with the environment private key information configured by the trusted execution environment; the approved state is obtained after the resource client verifies the signature of the approval signature information with the public key information of the approval object obtained from the trusted execution environment and configures the approval state of the resource transfer transaction when the signature verification is successful; the approval signature information is obtained after the approval terminal signs the resource transfer transaction with the private key information of the approval object; the multi-signature information associated with the approval object includes the approval signature information obtained after the approval terminal approves the resource transfer transaction. For the specific process of generating the signed resource transfer transaction, reference can be made to the corresponding embodiment above Figure 3 and will not be elaborated here

[0166] Step S302: Verify the signature of the second transaction signature information with the public key information of the first service object, and when the signature verification is successful, obtain the environment public key information corresponding to the environment private key information from the resource service contract associated with the resource client

[0167] It can be understood that after obtaining the signed resource transfer transaction, the blockchain node can perform signature verification on the first transaction signature information and the second transaction signature information through the environment public key information corresponding to the environment private key information and the public key information of the first business object. Among them, performing signature verification on the first transaction signature information through the environment public key information can be used to determine whether the result of the resource transfer transaction passing the approval has been confirmed by the trusted execution environment (because only when the approval is passed will the environment private key information be used to perform transaction signature on the resource transfer transaction), thereby improving the reliability of the off-chain approval process and the security of transaction on-chain. Performing signature verification on the second transaction signature information through the public key information of the first business object can be used to determine whether the resource transfer transaction is initiated by the first business object and whether the resource transfer transaction has been tampered with, thereby ensuring the security and integrity of the transaction.

[0168] Among them, optionally, the embodiment of the present application can first verify the second transaction signature information, and when the verification of the second transaction signature information is successful, then perform signature verification on the first transaction signature information. In this way, when the verification of the previously verified signature information fails, the subsequent signature information does not need to be continuously verified, thereby reducing the resource consumption for signature verification and the memory occupancy of the blockchain node; or, optionally, the first transaction signature information and the second transaction signature information can also be verified in parallel. Verifying the two signature information in parallel can improve the signature verification efficiency; the order of signature verification is not limited here.

[0169] For example, the blockchain node can perform signature verification on the second transaction signature information through the public key information of the first business object, and when the signature verification is successful, it can obtain the environment public key information corresponding to the environment private key information from the resource business contract associated with the resource client. Among them, the resource business contract is deployed on the blockchain corresponding to the blockchain network, and the data stored in the resource business contract mainly can include the environment public key information corresponding to the built-in environment private key information of the trusted execution environment, the account address allowed to operate the contract (such as the account address of the aforementioned first business object), relevant remote attestations (such as the first remote attestation corresponding to the approval passed status, the second remote attestation corresponding to the approval client), etc. The specific content of the resource business contract is not limited here.

[0170] Optionally, the public key information of the first business object can also be stored in the resource business contract, that is, the blockchain node can obtain the public key information of the first business object from the resource business contract to perform signature verification on the second transaction signature information; or, optionally, the public key information of the first business object can also be carried in the second transaction signature information, that is, the blockchain node can obtain the public key information of the first business object carried therein from the second transaction signature information to perform signature verification on the second transaction signature information; or, alternatively, the public key information of the first business object can also be stored in a public key certificate issued by a relevant institution, and the public key certificate can be stored on the blockchain, then the blockchain node can obtain the public key information of the first business object from the public key certificate. The embodiments of the present application do not limit the manner of obtaining the public key information of the first business object.

[0171] Step S303: Perform signature verification on the first transaction signature information through the environmental public key information, and when the signature verification is successful, transfer the business resources from the account address of the first business object to the account address of the second business object through the resource business contract.

[0172] It can be understood that after obtaining the environmental public key information, the blockchain node can perform signature verification on the first transaction signature information through the environmental public key information. When the signature verification is successful, it is equivalent to the trusted execution environment making an endorsement for the resource transfer transaction. At this time, the business resources can be transferred from the account address of the first business object to the account address of the second business object through the resource business contract.

[0173] Among them, the specific process of performing signature verification on the first transaction signature information through the environmental public key information can be: the blockchain node can perform signature verification on the first transaction signature information through the environmental public key information to obtain the to-be-verified digest information of the resource transfer transaction; when obtaining the transaction digest information of the resource transfer transaction, the to-be-verified digest information can be compared with the transaction digest information. If the to-be-verified digest information is consistent with the transaction digest information, it can be determined that the signature verification is successful; at this time, the business resources can be transferred from the account address of the first business object to the account address of the second business object through the resource business contract. Among them, the resource business contract may include a resource transfer method (or resource transfer function), and the business resources can be transferred from the account address of the first business object to the account address of the second business object by calling the resource transfer method.

[0174] It can be understood that the aforementioned approval client can perform a hash calculation on a resource transfer transaction in an approved state to obtain a digest information h of the resource transfer transaction, and use the environmental private key information configured by the trusted execution environment to digitally sign the digest information h to obtain a first transaction signature information. Correspondingly, the blockchain node can perform signature verification on the first transaction signature information through the environmental public key information to obtain the digest information h of the resource transfer transaction as the digest information to be verified, and can use the same hash algorithm as the aforementioned approval client to perform a hash calculation on the resource transfer transaction to obtain a digest information H of the resource transfer transaction as the transaction digest information; further, the digest information h obtained after signature verification can be compared with the digest information H obtained by performing the hash calculation; optionally, if the digest information h is different from the digest information H, it can be determined that the signature verification fails; optionally, if the digest information h is the same as the digest information H, it can be determined that the signature verification is successful, and thus the subsequent resource transfer operation can be executed.

[0175] It can be understood that the process of performing signature verification on the second transaction signature information through the public key information of the first business object in step S302 above can refer to the process of performing signature verification on the first transaction signature information through the environmental public key information in this step, which will not be elaborated here.

[0176] In addition, optionally, after the resource transfer is completed, any entity object with read permission can obtain the remote attestation corresponding to the approved state (such as the aforementioned first remote attestation) from the resource business contract and verify it with the corresponding institution. Passing the verification means that the result of the approval is generated by the trusted execution environment, thus ensuring the security and trustworthiness of the approval process.

[0177] Taking the first business object as an example, when the blockchain node obtains a proof acquisition request sent by the first business object through the resource client, it can call the resource business contract based on the proof acquisition request to obtain the first remote attestation corresponding to the approved state, and can send the first remote attestation to the resource client so that the resource client sends the first remote attestation to the remote authentication server for remote authentication. This process can refer to the relevant description in step S204 of the corresponding embodiment above, which will not be elaborated here. Figure 5 The relevant description in step S204 of the corresponding embodiment above, which will not be elaborated here.

[0178] It can be seen that the embodiment of the present application proposes an off-chain approval scheme based on a trusted execution environment. The approval process is placed in the trusted execution environment. When a user (i.e., the aforementioned first business object) requests a resource transfer, they only need to attach the execution result of the trusted execution environment and the signature information of the built-in private key of the trusted execution environment for the relevant transaction, and then a resource transfer can be achieved through a single transaction. The approval process is ensured to be correct by the trusted execution environment, and all blockchain nodes jointly witness the approval process. The embodiment of the present application combines the smart contract of the blockchain with the security of the trusted execution environment. By building the approval process into the trusted execution environment to perform off-chain approval of relevant transactions, it can achieve the security and reliability of the entire process from initiating a transaction -> transaction approval -> resource transfer, and there is no need to submit additional transactions, saving the approval cost.

[0179] Further, please refer to Figure 10 , Figure 10 which is a schematic diagram of a transfer process based on a trusted execution environment provided by an embodiment of the present application. As Figure 10 shown, an exemplary process of initiating a transfer -> approval -> transfer is demonstrated. This transfer process can be jointly executed by client 10a, terminal 10c, client 10e, and node 10g. Among them, client 10a is associated with user 10b. Client 10a can serve as the aforementioned resource client, and user 10b can serve as the aforementioned first business object; terminal 10c is associated with approver 10d. Terminal 10c can serve as the aforementioned approval terminal, and approver 10d can serve as the aforementioned approval object; client 10e runs in the trusted execution environment and can be used to execute the built-in approval logic 10f of the trusted execution environment. This client 10e can serve as the aforementioned approval client; node 10g can be any blockchain node in the blockchain network. For example, node 10g can be any blockchain node (such as node 100a) in the blockchain network 100 shown above. A business contract 10h is deployed on node 10g, and this business contract 10h can serve as the aforementioned resource business contract. The transfer process can specifically include the following steps: Figure 1 which are as follows:

[0180] Step S401, when user 10b hopes to transfer funds to user 10i (who can serve as the aforementioned second business object) (such as transferring assets of a specified amount), client 10a can initiate a corresponding transfer request and send this transfer request to the approval terminal of the relevant approver (such as terminal 10c) in the form of a transaction for approval;

[0181] Step S402, after terminal 10c receives the transaction Y2 corresponding to the transfer request (which can serve as the aforementioned resource transfer transaction), it can approve the transaction Y2 corresponding to the transfer request;

[0182] Step S403: The terminal 10c sends the approval result obtained from the approval of the transaction Y2 corresponding to the transfer request to the client 10e;

[0183] Among them, assuming that the terminal 10c is an approval terminal for aggregating the approval results of each approver, the terminal 10c can collect the signatures of the approvers (such as the approver 10d) who agree to the transfer request on the transaction Y2 through their private key information (which can be used as the aforementioned approval signature information), and combine the collected signatures into a signature set (which can be used as the aforementioned multi-signature information) and send it to the client 10e together, so that the client 10e can execute the approval logic 10f.

[0184] Step S404: After the client 10e receives the approval results of each approver (specifically, the multi-signature information associated with the approver), it can judge whether the transfer request (corresponding transaction Y2) of the user 10b passes the approval according to the approval passing conditions set in the approval logic 10f;

[0185] Step S405: When the transfer request passes the approval, the client 10e can sign the transaction Y2 corresponding to the transfer request through the built-in private key of the trusted execution environment (which can be used as the aforementioned environment private key information), and can generate a remote attestation about the approval passing result (which can be used as the aforementioned first remote attestation corresponding to the approval passing status) according to the measurement value of the client 10e (which can be used as the program measurement value of the aforementioned approval client), the relevant information of the approval passing result (which can be used as the aforementioned first service information), and the internal relevant parameters of the trusted execution environment (which can be used as the aforementioned environment parameter information associated with the trusted execution environment, such as the current version of the TEE or the unique serial number of the TEE), so as to ensure that this approval passing result is generated by the trusted execution environment; return the signature of the transaction Y2 and the remote attestation of the approval passing result to the client 10a;

[0186] Step S406: The client 10a can submit the transfer request, the signature of the transaction Y2 corresponding to the transfer request (which can be used as the aforementioned first transaction signature information), and the remote attestation of the approval passing result to the node 10g in the form of a transaction. For example, it can submit the signed transaction Y3 corresponding to the transfer request (which can be used as the aforementioned signed resource transfer transaction) to the business contract 10h on the node 10g;

[0187] Step S407: The node 10g can call the business contract 10h and verify the signature of the aforementioned transaction Y2 through the public key of the trusted execution environment recorded in the business contract 10h (which can be used as the aforementioned environment public key information);

[0188] Step S408, when the signature verification is successful, node 10g can call business contract 10h to execute the transfer logic to transfer the specified resources (i.e., the aforementioned business resources, such as assets with a specified amount) from the account address of user 10b to the account address of user 10i.

[0189] As can be seen from the above, the embodiment of the present application combines the smart contract of the blockchain with the security of the trusted execution environment. By embedding the approval process in the trusted execution environment to perform off-chain approval on transfer requests, the security and reliability of the entire process of initiating transfer -> approval -> transfer can be achieved, and no additional transactions need to be submitted, saving approval costs.

[0190] Please refer to Figure 11 , Figure 11 is the structural schematic diagram of a data processing device based on a trusted execution environment provided by an embodiment of the present application Figure 1 . The data processing device 1 based on the trusted execution environment can be applied to an approval client, and the approval client runs in the trusted execution environment. For example, the approval client can be the client 22b in the corresponding embodiment above Figure 2a - Figure 2b . It should be understood that the data processing device 1 based on the trusted execution environment can be a computer program (including program code) running on the approval client (such as the aforementioned client 22b). For example, the data processing device 1 based on the trusted execution environment can be an application software; the device can be used to execute the corresponding steps in the data processing method based on the trusted execution environment provided by the embodiment of the present application. As Figure 11 shown, the data processing device 1 based on the trusted execution environment can include: a signature acquisition module 11, an approval verification module 12, a signature sending module 13, a first proof acquisition module 14, a second proof acquisition module 15, and a third proof acquisition module 16;

[0191] The signature acquisition module 11 is used to acquire multi-signature information associated with the approval object; the multi-signature information includes the approval signature information obtained after the approval terminal approves the resource transfer transaction; the approval signature information is obtained after the approval terminal signs the resource transfer transaction with the private key information of the approval object; the resource transfer transaction is a transaction initiated by the first business object through the resource client for transferring business resources to the second business object;

[0192] The approval verification module 12 is used to acquire the public key information of the approval object from the trusted execution environment, verify the signature of the approval signature information through the public key information of the approval object, and when the signature verification is successful, configure the approval status of the resource transfer transaction to the approved status, and sign the resource transfer transaction in the approved status through the environment private key information configured by the trusted execution environment to obtain the first transaction signature information;

[0193] Among them, the multi-signature information includes the approval signature information of M approval objects; M is a positive integer;

[0194] The approval verification module 12 may include: an approval signature verification unit 121 and an approval passing unit 122;

[0195] The approval signature verification unit 121 is used to obtain the public key information of M approval objects from the trusted execution environment, perform signature verification on the approval signature information of M approval objects through the public key information of M approval objects, and obtain the approval signature verification results corresponding to the M approval signature information; the approval signature verification results include the signature verification success result or the signature verification failure result corresponding to each approval signature information in the M approval signature information;

[0196] The approval passing unit 122 is used to determine that the signature verification is successful when the number of signature verification success results in the approval signature verification results meets the approval passing conditions configured by the approval client.

[0197] Among them, the approval passing conditions include an approval quantity threshold;

[0198] Specifically, the approval passing unit 122 is used to determine that the signature verification is successful when the number of signature verification success results in the approval signature verification results is greater than or equal to the approval quantity threshold.

[0199] Among them, the approval passing conditions include an approval ratio threshold;

[0200] Specifically, the approval passing unit 122 is used to obtain the signature verification success ratio between the number of signature verification success results in the approval signature verification results and the total number of approval objects; the total number of approval objects is a positive integer greater than or equal to M; when the signature verification success ratio is greater than or equal to the approval ratio threshold, determine that the signature verification is successful.

[0201] Among them, for the specific functional implementation manners of the approval signature verification unit 121 and the approval passing unit 122, reference may be made to the description of step S102 in the corresponding embodiment above, and details will not be elaborated here. Figure 3 The description corresponding to the above will not be repeated here.

[0202] The signature sending module 13 is used to send the first transaction signature information to the resource client, so that the resource client can perform transaction signature on the resource transfer transaction through the private key information of the first business object to obtain the second transaction signature information, determine the signed resource transfer transaction corresponding to the resource transfer transaction based on the first transaction signature information and the second transaction signature information, and send the signed resource transfer transaction to the blockchain nodes in the blockchain network; the signed resource transfer transaction is used to instruct the blockchain nodes to perform signature verification on the first transaction signature information and the second transaction signature information through the environmental public key information corresponding to the environmental private key information and the public key information of the first business object, and when the signature verification is successful, transfer the business resources from the account address of the first business object to the account address of the second business object.

[0203] The first proof obtaining module 14 is used to obtain the first remote proof corresponding to the approval passed status and send the first remote proof to the resource client, so that when the resource client sends the signed resource transfer transaction to the blockchain nodes, the first remote proof is sent to the blockchain nodes; the first remote proof is used to be written into the resource business contract deployed on the blockchain corresponding to the blockchain network.

[0204] Among them, the first proof obtaining module 14 may include: a signature generating unit 141 and a proof determining unit 142;

[0205] The signature generating unit 141 is used to obtain the first business information associated with the approval passed status, the program measurement value of the approval client, and the environmental parameter information associated with the trusted execution environment, and sign the first business information, the program measurement value, and the environmental parameter information through the environmental private key information to obtain the first proof signature information;

[0206] Among them, the signature generating unit 141 is specifically used to perform splicing processing on the first business information, the program measurement value, and the environmental parameter information to obtain the first spliced data; sign the first spliced data through the environmental private key information to obtain the first proof signature information.

[0207] The proof determining unit 142 is used to determine the first remote proof corresponding to the approval passed status based on the first business information, the program measurement value, the environmental parameter information, and the first proof signature information.

[0208] Among them, for the specific functional implementation manners of the signature generating unit 141 and the proof determining unit 142, reference may be made to the description of step S204 in the corresponding embodiment above, and details will not be elaborated here. Figure 5 The description of the corresponding embodiment will not be continued here.

[0209] The second proof acquisition module 15 is configured to, when receiving a proof generation request sent by the first service object through the resource client, obtain the program measurement value of the approval client and the environment parameter information associated with the trusted execution environment based on the proof generation request, and obtain the second service information associated with the first service object from the proof generation request; sign the program measurement value, the second service information, and the environment parameter information with the environment private key information to obtain the second proof signature information; determine the second remote proof corresponding to the approval client based on the program measurement value, the second service information, the environment parameter information, and the second proof signature information, and send the second remote proof to the resource client, so that the resource client sends the second remote proof to the remote authentication server for remote authentication.

[0210] The third proof acquisition module 16 is configured to, when the signature verification fails, configure the approval status of the resource transfer transaction as the unapproved status, obtain the third remote proof corresponding to the unapproved status, and generate a transfer failure prompt message based on the unapproved status, and send the third remote proof and the transfer failure prompt message to the resource client.

[0211] Among them, for the specific functional implementation manners of the signature acquisition module 11, the approval verification module 12, the signature sending module 13, the first proof acquisition module 14, the second proof acquisition module 15, and the third proof acquisition module 16, reference can be made to the descriptions of steps S101 - S103 in the corresponding embodiments above, or reference can be made to the descriptions of steps S201 - S206 in the corresponding embodiments above. Details will not be elaborated here. It should be understood that the descriptions of the beneficial effects obtained by using the same method will not be elaborated either. Figure 3 Please refer to Figure 5 for details.

[0212] Please refer to Figure 12 , Figure 12 FIG. 2 is a second structural schematic diagram of a data processing device based on a trusted execution environment provided by an embodiment of the present application. As Figure 12 shown, the data processing device 2 based on the trusted execution environment can be applied to any blockchain node in the blockchain network. For example, the blockchain node can be the node 20a in the corresponding embodiment above. It should be understood that the data processing device 2 based on the trusted execution environment can be a computer program (including program code) running on a blockchain node (such as the aforementioned node 20a). For example, the data processing device 2 based on the trusted execution environment can be an application software; the device can be used to execute the corresponding steps in the data processing method based on the trusted execution environment provided by the embodiment of the present application. As Figure 2a - Figure 2b shown, Figure 12As shown in the figure, the data processing device 2 based on the trusted execution environment may include: a transaction acquisition module 21, a first verification module 22, a second verification module 23, and a proof authentication module 24;

[0213] The transaction acquisition module 21 is configured to obtain a signed resource transfer transaction corresponding to a resource transfer transaction. A resource transfer transaction refers to a transaction initiated by a first business object through a resource client for transferring business resources to a second business object. The signed resource transfer transaction is determined based on a first transaction signature information and a second transaction signature information when the resource client signs the resource transfer transaction with the private key information of the first business object to obtain the second transaction signature information. The first transaction signature information is obtained after the resource client signs the resource transfer transaction in an approved state with the environment private key information configured by the trusted execution environment. The approved state is obtained after the resource client verifies the signature of the approval signature information with the public key information of the approval object obtained from the trusted execution environment and configures the approval state of the resource transfer transaction when the signature verification is successful. The approval signature information is obtained after the approval terminal signs the resource transfer transaction with the private key information of the approval object. The multi-signature information associated with the approval object includes the approval signature information obtained after the approval terminal approves the resource transfer transaction.

[0214] The first verification module 22 is configured to verify the signature of the second transaction signature information with the public key information of the first business object, and when the signature verification is successful, obtain the environment public key information corresponding to the environment private key information from the resource business contract associated with the resource client. The resource business contract is deployed on the blockchain corresponding to the blockchain network.

[0215] The second verification module 23 is configured to verify the signature of the first transaction signature information with the environment public key information, and when the signature verification is successful, transfer the business resources from the account address of the first business object to the account address of the second business object through the resource business contract.

[0216] Among them, the second verification module 23 may include: a signature verification unit 231 and a resource transfer unit 232;

[0217] The signature verification unit 231 is configured to verify the signature of the first transaction signature information with the environment public key information to obtain the to-be-verified digest information of the resource transfer transaction. When obtaining the transaction digest information of the resource transfer transaction, compare the to-be-verified digest information with the transaction digest information. If the to-be-verified digest information is consistent with the transaction digest information, it is determined that the signature verification is successful.

[0218] A resource transfer unit 232 is configured to transfer business resources from the account address of a first business object to the account address of a second business object through a resource business contract.

[0219] Among them, for the specific functional implementation manners of the signature verification unit 231 and the resource transfer unit 232, reference may be made to the description of step S303 in the corresponding embodiment above. Figure 9 Details will not be elaborated herein.

[0220] A proof authentication module 24 is configured to, when receiving a proof acquisition request sent by a first business object through a resource client, call a resource business contract based on the proof acquisition request to obtain a first remote proof corresponding to an approval passed status, and send the first remote proof to the resource client, so that the resource client sends the first remote proof to a remote authentication server for remote authentication.

[0221] Among them, for the specific functional implementation manners of the transaction acquisition module 21, the first verification module 22, the second verification module 23, and the proof authentication module 24, reference may be made to the description of steps S301 - S303 in the corresponding embodiment above. Details will not be elaborated herein. It should be understood that the description of the beneficial effects obtained by using the same method will not be elaborated either. Figure 9 Please refer to

[0222] which Figure 13 is Figure 13 a schematic structural diagram of a computer device provided by an embodiment of the present application. As Figure 13 shown, the computer device 1000 may include: a processor 1001, a network interface 1004, and a memory 1005. In addition, the computer device 1000 may further include: a user interface 1003 and at least one communication bus 1002. Among them, the communication bus 1002 is used to implement connection communication between these components. Among them, the optional user interface 1003 may include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory, such as at least one disk memory. The memory 1005 may optionally be at least one storage device located far from the aforementioned processor 1001. As Figure 13 shown, the memory 1005, as a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

[0223] In Figure 13In the computer device 1000 shown, the network interface 1004 can provide network communication functions; the user interface 1003 is mainly used to provide an interface for users to input; and the processor 1001 can be used to call the device control application program stored in the memory 1005 to execute the content described in any of the previous Figure 3 , Figure 5 , Figure 9 corresponding embodiments of the data processing method based on the trusted execution environment, which will not be elaborated here. In addition, the description of the beneficial effects of adopting the same method will not be elaborated either.

[0224] In addition, it should be pointed out here that: The embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores the computer programs executed by the data processing device 1 and the data processing device 2 based on the trusted execution environment mentioned above, and the computer program includes computer instructions. When the processor executes the computer instructions, it can execute the content described in any of the previous Figure 3 , Figure 5 , Figure 9 corresponding embodiments of the data processing method based on the trusted execution environment. Therefore, it will not be elaborated here. In addition, the description of the beneficial effects of adopting the same method will not be elaborated either. For the technical details not disclosed in the embodiment of the computer-readable storage medium involved in the present application, please refer to the description of the method embodiment of the present application.

[0225] The above computer-readable storage medium may be the data processing device provided in any of the foregoing embodiments or the internal storage unit of the above computer device, such as the hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk equipped on the computer device, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. Further, the computer-readable storage medium may also include both the internal storage unit and the external storage device of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium may also be used to temporarily store the data that has been output or will be output.

[0226] In addition, it should be pointed out here that: The embodiment of the present application also provides a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the content described in the previousFigure 3 , Figure 5 , Figure 9 Any method provided by the corresponding embodiment. In addition, the description of the beneficial effects of the same method will not be repeated. For technical details not disclosed in the computer program product or computer program embodiment involved in this application, please refer to the description of the method embodiment of this application.

[0227] For further information, see Figure 14 , Figure 14 Schematic diagram of a data processing system based on a trusted execution environment provided by an embodiment of the present application. Figure 14 As shown, the data processing system 3 based on the trusted execution environment may include an approval client 1a and a blockchain node 2a. The approval client 1a may be the above Figure 2a - Figure 2b The approval client (such as client 22b) described in the corresponding embodiment can be run on the above Figure 1 Any terminal device (such as terminal device 200a) in the terminal cluster shown in the figure will not be described in detail here. Among them, blockchain node 2a can be the above Figure 2a - Figure 2b The blockchain node described in the corresponding embodiment (such as node 20a) can be the above-mentioned Figure 1 Any blockchain node in the blockchain network shown will not be described here. In addition, the description of the beneficial effects of the same method will not be repeated. For technical details not disclosed in the embodiment of the data processing system based on the trusted execution environment involved in this application, please refer to the description of the method embodiment of this application.

[0228] The terms "first", "second", etc. in the description, claims, and drawings of the embodiments of the present application are used to distinguish different objects, rather than to describe a specific order. In addition, the term "comprising" and any of their variations are intended to cover non-exclusive inclusions. For example, a process, method, device, product, or equipment that includes a series of steps or units is not limited to the listed steps or modules, but optionally includes steps or modules that are not listed, or optionally includes other step units inherent to these processes, methods, devices, products, or equipment.

[0229] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0230] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of the examples have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0231] It should be noted that for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that this application is not limited by the described action sequence, because according to this application, some steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0232] The steps in the method embodiments of this application can be adjusted, combined, and deleted according to actual needs.

[0233] The modules in the device embodiments of this application can be combined, divided, and deleted according to actual needs.

[0234] Those of ordinary skill in the art can understand that implementing all or part of the processes in the above method embodiments can be achieved by instructing relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the method embodiments as described above. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM), etc.

[0235] The foregoing disclosure is only the preferred embodiments of this application. Of course, the scope of rights of this application cannot be limited thereby. Therefore, equivalent changes made according to the claims of this application still fall within the scope covered by this application.

Claims

1. A data processing method based on a trusted execution environment, characterized in that, the method is executed by an approval client, the approval client runs in the trusted execution environment, and the method includes: obtaining multi-signature information associated with an approval object; the multi-signature information includes approval signature information obtained after the approval terminal approves a resource transfer transaction; the approval signature information is obtained after the approval terminal signs the resource transfer transaction with the private key information of the approval object; the resource transfer transaction is a transaction initiated by a first business object through a resource client and used to transfer business resources to a second business object; obtaining the public key information of the approval object from the trusted execution environment, verifying the signature of the approval signature information through the public key information of the approval object, and when the signature verification is successful, configuring the approval status of the resource transfer transaction to the approved status, and signing the resource transfer transaction in the approved status through the environment private key information configured by the trusted execution environment to obtain first transaction signature information; sending the first transaction signature information to the resource client, so that the resource client signs the resource transfer transaction with the private key information of the first business object to obtain second transaction signature information, determining the signed resource transfer transaction corresponding to the resource transfer transaction based on the first transaction signature information and the second transaction signature information, and sending the signed resource transfer transaction to a blockchain node in the blockchain network; the signed resource transfer transaction is used to instruct the blockchain node to verify the signatures of the first transaction signature information and the second transaction signature information through the environment public key information corresponding to the environment private key information and the public key information of the first business object, and when the signature verification is successful, transfer the business resources from the account address of the first business object to the account address of the second business object.

2. The method according to claim 1, characterized in that, the multi-signature information includes the approval signature information of M approval objects; M is a positive integer; the obtaining the public key information of the approval object from the trusted execution environment and verifying the signature of the approval signature information through the public key information of the approval object includes: obtaining the public key information of the M approval objects from the trusted execution environment, verifying the signatures of the approval signature information of the M approval objects through the public key information of the M approval objects to obtain approval signature verification results corresponding to the M approval signature information; the approval signature verification results include a verification success result or a verification failure result corresponding to each approval signature information in the M approval signature information; determining that the signature verification is successful when the number of verification success results in the approval signature verification results meets the approval passing condition configured by the approval client.

3. The method according to claim 2, characterized in that, the approval passing condition includes an approval quantity threshold; When the number of successful signature verification results in the approval signature verification results meets the approval passing condition configured by the approval client, it is determined that the signature verification is successful, including: When the number of successful signature verification results in the approval signature verification results is greater than or equal to the approval quantity threshold, it is determined that the signature verification is successful.

4. The method according to claim 2, wherein, the approval passing condition includes an approval ratio threshold; When the number of successful signature verification results in the approval signature verification results meets the approval passing condition configured by the approval client, it is determined that the signature verification is successful, including: Obtain the signature verification success ratio between the number of successful signature verification results in the approval signature verification results and the total number of approval objects; the total number of approval objects is a positive integer greater than or equal to M; When the signature verification success ratio is greater than or equal to the approval ratio threshold, it is determined that the signature verification is successful.

5. The method according to claim 1, wherein, further comprising: Obtain a first remote attestation corresponding to the approval passing status, and send the first remote attestation to the resource client, so that when the resource client sends the signed resource transfer transaction to the blockchain node, the first remote attestation is sent to the blockchain node; The first remote attestation is used to be written into the resource business contract deployed on the blockchain corresponding to the blockchain network.

6. The method according to claim 5, wherein, the obtaining of the first remote attestation corresponding to the approval passing status includes: Obtain first service information associated with the approval passing status, the program measurement value of the approval client, and environment parameter information associated with the trusted execution environment, and sign the first service information, the program measurement value, and the environment parameter information through the environment private key information to obtain first proof signature information; Based on the first service information, the program measurement value, the environment parameter information, and the first proof signature information, determine the first remote attestation corresponding to the approval passing status.

7. The method according to claim 6, wherein, the signing of the first service information, the program measurement value, and the environment parameter information through the environment private key information to obtain first proof signature information includes: Perform splicing processing on the first service information, the program measurement value, and the environment parameter information to obtain first spliced data; Sign the first spliced data through the environment private key information to obtain first proof signature information.

8. The method according to claim 1, wherein, further comprising: When receiving a proof generation request sent by the first service object through the resource client, obtain the program measurement value of the approval client and the environment parameter information associated with the trusted execution environment based on the proof generation request, and obtain second service information associated with the first service object from the proof generation request; Sign the program measurement value, the second service information, and the environment parameter information through the environment private key information to obtain second proof signature information; Based on the program metric value, the second service information, the environment parameter information, and the second proof signature information, determine the second remote proof corresponding to the approval client, and send the second remote proof to the resource client, so that the resource client sends the second remote proof to a remote authentication server for remote authentication.

9. The method according to claim 1, wherein, it further includes: When the signature verification fails, configure the approval status of the resource transfer transaction to the status of disapproval, obtain a third remote proof corresponding to the status of disapproval, and generate a transfer failure prompt message based on the status of disapproval, and send the third remote proof and the transfer failure prompt message to the resource client.

10. A data processing method based on a trusted execution environment, wherein, the method is executed by a blockchain node in a blockchain network, and the method includes: Obtain a signed resource transfer transaction corresponding to a resource transfer transaction; the resource transfer transaction refers to a transaction initiated by a first service object through a resource client for transferring service resources to a second service object; the signed resource transfer transaction is determined based on a first transaction signature information and the second transaction signature information when the resource client signs the resource transfer transaction with the private key information of the first service object to obtain the second transaction signature information; the first transaction signature information is obtained after the resource client signs the resource transfer transaction in an approval passed state with the environment private key information configured by the trusted execution environment; the approval passed state is obtained after the resource client configures the approval status of the resource transfer transaction by performing signature verification on approval signature information with the public key information of an approval object obtained from the trusted execution environment and when the signature verification is successful; the approval signature information is obtained after an approval terminal signs the resource transfer transaction with the private key information of the approval object; the multi-signature information associated with the approval object includes the approval signature information obtained after the approval terminal approves the resource transfer transaction; Perform signature verification on the second transaction signature information with the public key information of the first service object, and when the signature verification is successful, obtain the environment public key information corresponding to the environment private key information from a resource service contract associated with the resource client; the resource service contract is deployed on a blockchain corresponding to the blockchain network; Perform signature verification on the first transaction signature information with the environment public key information, and when the signature verification is successful, transfer the service resources from the account address of the first service object to the account address of the second service object through the resource service contract.

11. The method according to claim 10, wherein, Performing signature verification on the first transaction signature information using the environmental public key information, and when the signature verification is successful, transferring the service resources from the account address of the first service object to the account address of the second service object through the resource service contract, includes: Performing signature verification on the first transaction signature information using the environmental public key information to obtain the to-be-verified digest information of the resource transfer transaction; When obtaining the transaction digest information of the resource transfer transaction, comparing the to-be-verified digest information with the transaction digest information, and if the to-be-verified digest information is consistent with the transaction digest information, determining that the signature verification is successful; Transferring the service resources from the account address of the first service object to the account address of the second service object through the resource service contract.

12. The method according to claim 10, wherein, it further includes: When obtaining a proof acquisition request sent by the first service object through the resource client, calling the resource service contract based on the proof acquisition request to obtain a first remote proof corresponding to the approval passed status, and sending the first remote proof to the resource client so that the resource client sends the first remote proof to a remote authentication server for remote authentication.

13. A data processing device based on a trusted execution environment, wherein, the device runs on an approval client, the approval client runs in the trusted execution environment, and the device includes: A signature acquisition module, configured to acquire multi-signature information associated with an approval object; the multi-signature information includes approval signature information obtained after a transaction approval terminal approves a resource transfer transaction; the approval signature information is obtained after the approval terminal performs transaction signature on the resource transfer transaction using the private key information of the approval object; the resource transfer transaction is a transaction initiated by a first service object through a resource client for transferring service resources to a second service object; An approval verification module, configured to obtain the public key information of the approval object from the trusted execution environment, perform signature verification on the approval signature information using the public key information of the approval object, and when the signature verification is successful, configure the approval status of the resource transfer transaction to the approval passed status, and perform transaction signature on the resource transfer transaction in the approval passed status using the environmental private key information configured by the trusted execution environment to obtain first transaction signature information; A signature sending module, configured to send the first transaction signature information to the resource client, so that the resource client signs the resource transfer transaction with the private key information of the first business object to obtain second transaction signature information, determine the signed resource transfer transaction corresponding to the resource transfer transaction based on the first transaction signature information and the second transaction signature information, and send the signed resource transfer transaction to a blockchain node in the blockchain network; the signed resource transfer transaction is used to instruct the blockchain node to perform signature verification on the first transaction signature information and the second transaction signature information with the environment public key information corresponding to the environment private key information and the public key information of the first business object, and when the signature verification is successful, transfer the business resources from the account address of the first business object to the account address of the second business object.

14. A data processing device based on a trusted execution environment, characterized in that the device runs on a blockchain node in the blockchain network, and the device includes: A transaction acquisition module, configured to acquire a signed resource transfer transaction corresponding to a resource transfer transaction; the resource transfer transaction refers to a transaction initiated by a first business object through a resource client for transferring business resources to a second business object; the signed resource transfer transaction is determined based on the first transaction signature information and the second transaction signature information when the resource client signs the resource transfer transaction with the private key information of the first business object to obtain the second transaction signature information; the first transaction signature information is obtained after the resource client signs the resource transfer transaction in an approved state with the environment private key information configured by the trusted execution environment; the approved state is obtained after the resource client performs signature verification on the approval signature information with the public key information of the approval object obtained from the trusted execution environment and configures the approval state of the resource transfer transaction when the signature verification is successful; the approval signature information is obtained after an approval terminal signs the resource transfer transaction with the private key information of the approval object; the multi-signature information associated with the approval object includes the approval signature information obtained after the approval terminal approves the resource transfer transaction; A first verification module, configured to perform signature verification on the second transaction signature information with the public key information of the first business object, and when the signature verification is successful, obtain the environment public key information corresponding to the environment private key information from a resource business contract associated with the resource client; the resource business contract is deployed on the blockchain corresponding to the blockchain network; A second verification module, configured to perform signature verification on the first transaction signature information with the environment public key information, and when the signature verification is successful, transfer the business resources from the account address of the first business object to the account address of the second business object through the resource business contract.

15. A computer device, It is characterized in that including a processor and a memory The processor is connected to the memory, wherein the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method according to any one of claims 1-12 16. A computer-readable storage medium It is characterized in that A computer program is stored in the computer-readable storage medium, and the computer program is adapted to be loaded and executed by a processor so that a computer device having the processor executes the method according to any one of claims 1-12 17. A computer program product It is characterized in that The computer program product includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The computer instructions are adapted to be read and executed by a processor so that a computer device having the processor executes the method according to any one of claims 1-12

Images