A privacy block synchronization method and system based on a trusted execution environment

Abstract

The application discloses a privacy block synchronization method and system based on a trusted execution environment, comprising a receiver and a sender, and the receiver and the sender are both hybrid architectures of host computers and TEEs, the method is executed by the receiver, and comprises the following steps: when the block height of the receiver TEE falls behind the block height of the receiver host computer, the receiver host computer selects a well-conditioned node from a node list as a sender, and sends a privacy block synchronization request to the sender; the host computer of the sender acquires privacy block information from a state database of the sender TEE according to the privacy block synchronization request, and returns the privacy block information to the receiver after encapsulation through AEAD; and the receiver TEE performs AEAD verification, and completes the whole privacy block synchronization process after verification. Through the built-in AEAD mechanism of the trusted execution environment, end-to-end privacy protection and integrity authentication of sensitive block synchronization data are realized, and the security is improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to a privacy block synchronization method and system based on a trusted execution environment. Background Technology

[0002] In a blockchain node architecture, when an untrusted host machine exists, sensitive synchronization data (e.g., transaction read / write sets) faces privacy and integrity threats when passing through untrusted transmission paths. Therefore, end-to-end data protection across trusted execution environments cannot be achieved.

[0003] Traditional blockchain synchronization mechanisms handle situations where nodes need to update local data after joining the network or going offline. When a node finds its block height lagging behind the latest on-chain state, it randomly selects another node as a data source through the peer-to-peer network and requests the transmission of the missing block data. This data typically includes the block header, transaction information, and read / write sets generated by transaction execution. After obtaining the data, the receiving node uses methods such as digital signature verification or Merkle tree proofs to confirm the authenticity of the block source and the completeness of the transaction list. Finally, it stores the verified block in its local database to complete state synchronization.

[0004] However, traditional blockchain synchronization mechanisms rely solely on digital signatures or Merkle trees at the consensus layer for authenticity and integrity verification, lacking end-to-end privacy protection for sensitive synchronization data (such as transaction read / write sets). Especially in TEE-host computer hybrid architectures, data is completely exposed on untrusted host computers and network transmission paths, making it vulnerable to privacy leaks and tampering, failing to meet the high-security synchronization requirements for cross-TEE authentication and privacy.

[0005] Patent document CN121037387A discloses a block synchronization method, apparatus, terminal device, and computer program product, comprising: synchronizing blocks in the current batch using a first synchronization method and calculating a first synchronization rate for the blocks in the current batch; updating a preset first synchronization rate sequence based on the first synchronization rate to obtain a third synchronization rate sequence, wherein the first synchronization rate sequence includes multiple synchronization rates, each of the multiple synchronization rates corresponding to a batch of blocks synchronized using the first synchronization method, and each batch containing the same number of blocks; calculating a first rate of the first synchronization method based on the third synchronization rate sequence; comparing a first product of the first rate and a preset value with a preset second rate, and determining the synchronization method for the next batch of blocks based on the comparison result. This application solves the problem in related technologies where a fixed block synchronization method configuration leads to reduced block synchronization efficiency, such as... Figure 1 As shown.

[0006] However, this method improves efficiency by dynamically switching synchronization modes, and its design focuses entirely on performance optimization, lacking mechanisms to ensure data integrity and privacy, and failing to consider protection against malicious nodes or network attacks. Therefore, it is not suitable for blockchain scenarios requiring high security and trust.

[0007] Patent document CN121051780A discloses a data processing method, apparatus, node device, and storage medium, comprising: acquiring transaction data of a target transaction, the transaction data including content data and strategy data of the target transaction; the strategy data being used to instruct at least one node device in a blockchain network to have execution authority over the target transaction; synchronizing the strategy data to each node device in the blockchain network, and sending the content data to a second node device with execution authority according to the instructions of the strategy data, so that the second node device executes the content data based on its execution authority; receiving the execution result of the content data by the second node device, and generating a transaction proposal based on the execution result; and broadcasting the transaction proposal to the blockchain network for consensus processing, which can ensure the security of transaction data with data privacy in the blockchain network, such as... Figure 2 As shown.

[0008] However, this method does not propose a specific mechanism for synchronizing privacy-preserving data between trusted off-chain hardware. It relies on policy data and node consensus to ensure privacy, but if the host computer of a node acts maliciously or there is inconsistency between hardware states, it lacks end-to-end verification methods such as AEAD sealing / desealing, which cannot guarantee the integrity and source trust of the read and write sets during the synchronization process, and is difficult to deal with security risks in real-world scenarios such as hardware restarts and catch-up.

[0009] Patent document CN115769547A discloses a database synchronization system using blockchain in a high-security region. Service providers such as electronic payment providers may maintain data storage across different regions, which may require data synchronization across these regions. Therefore, this technology combines InterPlanetary File System (IPFS) technology with blockchain technology to provide data storage, creating a secure, scalable, and reliable data synchronization system. IPFS can be implemented as a data storage layer, and blockchain can be implemented as a transaction management system, where the IPFS address and synchronization point of data files are stored in a distributed ledger. In various aspects, the integration of the IPFS network with the structured network can enhance IPFS and the structured network to create a more secure file-sharing platform, thereby improving data transmission and database synchronization between different regions, such as... Figure 3 As shown.

[0010] However, this method relies on two layers of networks, IPFS and blockchain, for data synchronization. Its complex architecture requires maintaining multiple network components, resulting in high deployment and maintenance costs. Furthermore, cross-network data processing and consensus mechanisms introduce significant performance overhead and synchronization latency. Moreover, its data consistency depends on distributed consensus rather than a direct hardware-based trust mechanism, impacting real-time performance and reliability. Summary of the Invention

[0011] To address this issue, this application provides a privacy block synchronization method and system based on a trusted execution environment, in order to solve the problem that sensitive synchronized data cannot achieve end-to-end data protection across trusted execution environments in a blockchain node architecture that includes an untrusted host computer.

[0012] To achieve the above objectives, this application provides the following technical solution:

[0013] Firstly, a privacy block synchronization method based on a trusted execution environment includes a receiver and a sender. Both the receiver and the sender are hybrid architectures of a host computer and a TEE. The receiver includes a first host computer and a first TEE, and the sender includes a second host computer and a second TEE. The method is executed by the receiver and includes:

[0014] Step 1: When the block height of the first TEE lags behind the block height of the first host computer, the first host computer selects a node with good status from the node list as the sender;

[0015] Step 2: The first host computer sends a privacy block synchronization request to the sender; the sender's second host computer receives the privacy block synchronization request, retrieves privacy block information from the status database of the second TEE according to the privacy block synchronization request, and returns the privacy block information to the receiver after encapsulating it with AEAD; the privacy block information includes ciphertext, AEAD authentication tag, random number, and associated data;

[0016] Step 3: The first host computer receives the privacy block information returned by the sender and pushes the privacy block information to the first TEE;

[0017] Step 4: The first TEE receives the privacy block information and extracts the version number from the associated data in the privacy block information through the privacy contract execution engine. It then performs AEAD verification based on the key of the version number. After the AEAD verification is successful, the ciphertext is decrypted according to a random number, and the plaintext privacy block write set is obtained. The privacy block write set is then stored in the database, thereby completing the entire privacy block synchronization process.

[0018] Optionally, the first host computer and the first TEE, as well as the second host computer and the second TEE, communicate through the driver layer interface and the internal gRPC.

[0019] Optionally, in step 2, the first host computer sends the privacy block synchronization request to the sender via a p2p network.

[0020] Optionally, in step 2, when the first host computer sends a privacy block synchronization request to the sender, it can request blocks of multiple heights at once.

[0021] Optionally, in step 2, when obtaining privacy block information from the state database of the second TEE according to the privacy block synchronization request, the specific steps include: the second host computer of the sender sending a request to the second TEE to obtain privacy block information; the second TEE receiving the obtained privacy block information and calling the privacy contract execution engine; the privacy contract execution engine obtaining the privacy block write set corresponding to the block height in the privacy block synchronization request from the state database of the second TEE, using the privacy block write set as plaintext, the block height and the version number of the currently used sm4 symmetric key as associated data, generating a random number, and using the currently used sm4 symmetric key to perform AEAD encapsulation operation to obtain ciphertext and AEAD authentication tag.

[0022] Optionally, when retrieving the privacy block write set of the corresponding height from the state database of the second TEE, multiple privacy block write sets of different heights can be retrieved at once.

[0023] Optionally, in step 4, if AEAD verification fails, the first host computer will remove the sender from the node list and add it to the blacklist.

[0024] Optionally, if the receiver does not receive the privacy block information returned by the sender within a preset time, the sender will be removed from the node list and added to the blacklist.

[0025] Optionally, the receiver will ignore the nodes in the blacklist for a preset time. After the preset time, if the status information of the nodes in the blacklist is good, they will be added back to the node list of the first host computer.

[0026] Secondly, a privacy block synchronization system based on a trusted execution environment includes multiple blockchain nodes, each blockchain node including a host computer and a TEE, wherein the host computer and the TEE communicate through a driver layer interface and an internal gRPC.

[0027] The host computer includes a network module, a synchronization module, a gRPC client, and a state database. The network module is used to communicate with other blockchain nodes. The synchronization module is used to implement the privacy block synchronization method based on a trusted execution environment. The gRPC client is used to initiate calls to the TEE and communicate. The state database is used to store the plaintext state data of the host computer.

[0028] The TEE includes a gRPC server, a privacy contract execution engine, and a state database. The gRPC server is used to receive gRPC calls from the host computer; the privacy contract execution engine is used to execute privacy transactions within the TEE's isolated environment; and the state database is used to store privacy state data within the TEE.

[0029] Compared with the prior art, this application has at least the following beneficial effects:

[0030] 1. This application provides a privacy-preserving block synchronization method based on a Trusted Execution Environment (TEE), comprising a receiver and a sender. The sender (TEE) uses AEAD to encrypt and encapsulate sensitive data for integrity, and transmits the ciphertext, authentication tag, and associated data to the receiver via an untrusted host computer for AEAD verification. The receiver (TEE) only needs one AEAD verification to simultaneously verify the confidentiality, integrity, and authentication of the data. This application achieves end-to-end privacy protection and integrity authentication of sensitive block synchronization data by utilizing the AEAD mechanism built into the Trusted Execution Environment, thereby improving security.

[0031] 2. When retrieving the privacy block write set of the corresponding height from the state database of the second TEE, multiple privacy block write sets of different heights can be retrieved at once. Subsequently, only one AEAD verification is required, which realizes batch synchronization and greatly improves the efficiency of privacy block synchronization. Attached Figure Description

[0032] To more intuitively illustrate the prior art and this application, exemplary drawings are provided below. It should be understood that the specific shapes and structures shown in the drawings should not generally be regarded as limiting conditions for implementing this application; for example, based on the technical concept disclosed in this application and the exemplary drawings, those skilled in the art are able to easily make conventional adjustments or further optimizations to the addition / reduction / classification, specific shapes, positional relationships, connection methods, size ratios, etc. of certain units (components).

[0033] Figure 1 A flowchart illustrating a block synchronization method, apparatus, terminal device, and computer program product provided by the prior art;

[0034] Figure 2A flowchart illustrating a data processing method, apparatus, node device, and storage medium provided for the prior art;

[0035] Figure 3 A schematic diagram of a database synchronization system in a high-security zone using blockchain technology, provided by existing technology;

[0036] Figure 4 A flowchart of a privacy block synchronization method based on a trusted execution environment is provided in Embodiment 1 of this application;

[0037] Figure 5 This is a schematic diagram illustrating the interaction of a privacy block synchronization method based on a trusted execution environment, provided in Embodiment 1 of this application.

[0038] Figure 6 This is a schematic diagram of a privacy block synchronization system based on a trusted execution environment, provided in Embodiment 2 of this application;

[0039] Figure 7 This is a schematic diagram of a blockchain node structure in a privacy block synchronization system based on a trusted execution environment, provided in Embodiment 2 of this application.

[0040] Figure 8 The communication process between the host computer and the TEE is provided in Embodiment 2 of this application. Detailed Implementation

[0041] The present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0042] In the description of this application: unless otherwise stated, "a plurality of" means two or more. The terms "first," "second," "third," etc., in this application are intended to distinguish the objects referred to and do not have any special meaning in terms of technical connotation (e.g., they should not be construed as an emphasis on importance or order). Expressions such as "including," "comprising," and "having" also mean "not limited to" (certain units, components, materials, steps, etc.).

[0043] The terms used in this application, such as "upper," "lower," "left," "right," and "middle," are generally used to indicate the general relative positional relationship for the purpose of intuitive understanding by referring to the accompanying drawings, and are not absolute limitations on the positional relationship in the actual product.

[0044] In a hybrid architecture of blockchain host computer and TEE, there are four situations in which block synchronization is required:

[0045] 1. When a new node joins the blockchain network.

[0046] 2. The host computer of the node crashes, but the node's TEE works normally during the crash, and then the host computer restarts.

[0047] 3. The node's TEE crashes, while the node's host computer continues to operate normally, and then the TEE restarts.

[0048] 4. Both the host computer and TEE of the node crashed until the host computer restarted.

[0049] In the first scenario, both the host computer's state database and the TEE's state database need to be synchronized by blocks. The host computer's block synchronization is handled by its traditional synchronization module, which catches up on plaintext blocks. However, the synchronization of privacy blocks in the TEE is the problem this invention aims to address.

[0050] In the second scenario, after the host computer restarts, its block height often lags behind the latest blockchain height. Simultaneously, during the host computer's downtime, its TEE (Transport Equipment Environment), acting as an isolated environment, lacks external awareness, and its block height will also lag behind the latest blockchain height. The handling logic in this case is equivalent to the first scenario.

[0051] In the third scenario, during a TEE outage, the node lacks the ability to execute and verify privacy transactions. When a new block contains privacy transactions, the node will be unable to participate in consensus, causing the block to lag behind. However, the host computer's synchronization module will then catch up with the lagging plaintext block. Therefore, when the TEE restarts, the privacy block height within the TEE is lagging behind, and the synchronization of the TEE's privacy blocks is the problem this invention aims to address.

[0052] In the fourth case, after the host computer restarts, the block height of the host computer and the block height in the TEE will lag behind. In this case, the processing logic is equivalent to the first case.

[0053] In summary, plaintext block synchronization on the host computer will be handled by the host computer's traditional synchronization module. This invention addresses the issue of privacy block synchronization within the TEE (Trusted Execution Environment). When a node is performing privacy block synchronization, sensitive synchronization data will pass through untrusted host computers and network environments of other nodes; only the TEEs of other nodes are trusted.

[0054] A Trusted Execution Environment (TEE) is a secure zone built within a computing device through hardware isolation. It isolates sensitive code and data from the device's regular operating system and applications, ensuring that program execution and data processing within the TEE maintain privacy and integrity even if the host system is compromised or contains malware.

[0055] Example 1

[0056] This embodiment provides a privacy block synchronization method based on a trusted execution environment. This method can ensure the secure synchronization of privacy block data between blockchain nodes within a trusted execution environment in an untrusted host computer / network environment. (Synchronization, in blockchain, refers to the process of achieving data consistency between network nodes. Synchronization is triggered when a new node joins the network or when the local data of an existing node lags behind the latest on-chain state due to offline reasons. This process is completed by exchanging and verifying block data between nodes.)

[0057] Please see Figure 4 and Figure 5 This embodiment provides a privacy block synchronization method based on a trusted execution environment, including a receiver (node ​​A) and a sender (node ​​B). Both the receiver and the sender are based on a hybrid architecture of host computer and TEE. The receiver includes a first host computer (host computer A) and a first TEE (TEE A), and the sender includes a second host computer (host computer B) and a second TEE (TEE B). The method is executed by the receiver and includes:

[0058] S1: When the block height of the first TEE lags behind the block height of the first host computer, the first host computer selects a node in good condition from the node list as the sender;

[0059] Specifically, the host computer A of node A initiates a [gRPC periodic call] to its TEE A and checks whether the block height of TEE A is behind the block height of the host computer A.

[0060] If the block height of TEE A is equal to the block height of host computer A, it means that the privacy block height in TEE A is normal, and host computer A continues to perform [gRPC periodic calls]. If the block height of TEE A lags behind the block height of host computer A, it means that the privacy block height in TEE A is lagging behind, so [gRPC periodic calls] are stopped, and the privacy block synchronization logic (i.e., the privacy block synchronization method based on the trusted execution environment) is triggered.

[0061] After the privacy block synchronization logic is completed, the host computer A of node A selects a node in good condition from the node list as the sender.

[0062] S2: The first host computer sends a privacy block synchronization request to the sender; the second host computer of the sender receives the privacy block synchronization request, obtains privacy block information from the status database of the second TEE according to the privacy block synchronization request, and returns the privacy block information to the receiver after encapsulating it with AEAD; the privacy block information includes ciphertext, AEAD authentication tag, random number and associated data;

[0063] Specifically, host computer A sends a [privacy block synchronization request] to the sender via a p2p network, and simultaneously waits for the sender to return a [privacy block synchronization response]. It should be noted that in this embodiment, the [privacy block synchronization request] can request blocks of multiple heights at once.

[0064] If the wait times out, it means that the sending node (i.e., the sender) selected by node A has failed or has launched a silencing attack on node A. At this time, host computer A removes the sender from its node list, adds the node to the blacklist, and re-initiates [gRPC periodic call] to its TEE A.

[0065] It should be noted that after a sending node is added to the blacklist, the host computer A will not pay attention to the node's status information for a period of time. After a period of time, if the status information of the node is confirmed to be good, it will be added back to the node list of the host computer A.

[0066] If node B receives a [privacy block synchronization request], it will initiate a gRPC call to its TEE B to [get privacy block information]. After receiving the gRPC call to [get privacy block information] from its host B, TEE B will call the privacy contract execution engine within TEE B.

[0067] The privacy contract execution engine will retrieve the privacy block write set corresponding to the height in the [Privacy Block Synchronization Request] from the state database of TEE B, use the privacy block write set as plaintext, and use the block height and the version number of the currently used sm4 symmetric key as associated data. At the same time, it will generate a random number nonce and use the currently used sm4 symmetric key to perform AEAD encapsulation operation to obtain ciphertext and authentication tag.

[0068] Among them, AEAD (Authentication Encryption with Associated Data) is an encryption paradigm that simultaneously provides confidentiality, integrity, and authentication of ciphertext, and can also perform integrity verification on associated data that does not require encryption but needs to be verified. Symmetric key cryptography refers to a cryptosystem that uses the same key for both encryption and decryption. Its core characteristics are fast encryption and decryption speed and high efficiency, making it suitable for encrypting large amounts of data, such as file transfers and database encryption. In blockchain, the read-write set is key metadata generated during the execution of a smart contract. It explicitly records the set of read operations and the set of write operations performed during the execution of that transaction.

[0069] TEE B returns the ciphertext, authentication tag, nonce, and associated data obtained by AEAD encapsulation to host computer B as [privacy block information]. After obtaining the [privacy block information] from its TEE B, host computer B returns the [privacy block information] to the requested node A through the p2p network, which is the [privacy block synchronization response].

[0070] In the context of AEAD operations, associated data refers to data that does not require encryption but whose integrity must be protected; in cryptography, nonce specifically refers to a random or pseudo-random value that can only be used once in an encryption operation.

[0071] It should be noted that in this embodiment, TEE B can obtain multiple height privacy block write sets from the state database at once, and then use this multiple height block write set as plaintext to perform an AEAD encapsulation operation.

[0072] S3: The first host computer receives the privacy block information returned by the sender and pushes the privacy block information to the first TEE;

[0073] Specifically, after node A successfully receives the [privacy block synchronization response], host computer A initiates a gRPC call to TEE A to [push privacy block information].

[0074] S4: The first TEE receives the privacy block information and extracts the version number from the associated data in the privacy block information through the privacy contract execution engine. It performs AEAD verification based on the key of the version number. After the AEAD verification is successful, the ciphertext is decrypted according to the random number, and the privacy block write set of plaintext is obtained. The privacy block write set is stored in the database, thereby completing the entire privacy block synchronization process.

[0075] Specifically, after TEE A receives the gRPC call to push privacy block information, it calls its privacy contract execution engine to process the privacy block information.

[0076] The privacy contract execution engine extracts the version number from the associated data in the [Privacy Block Information] and uses the sm4 symmetric key with that version number for AEAD verification. If AEAD verification passes, it means the tag is consistent, and the ciphertext, nonce, and associated data are all consistent with the encryption end TEE B. Next, the ciphertext is decrypted using the sm4 symmetric key with that version number to obtain the plaintext block write set. This block write set at that height is then stored in the database, completing the entire privacy block synchronization process. Then, it continues to initiate [gRPC periodic calls] to its TEE A and checks whether the block height of TEE A lags behind the block height of the host computer A.

[0077] In this embodiment, if AEAD verification fails, it means:

[0078] [Privacy Block Information] When transmitted through untrusted host computers and untrusted network environments, the integrity of ciphertext or associated data may be compromised, leading to verification failure. For example, a malicious host computer may tamper with the ciphertext or associated data.

[0079] The failure to authenticate the [Privacy Block Information] indicates that the [Privacy Block Information] was not generated by a legitimate TEE, and may be a fake or illegal [Privacy Block Information] generated by a malicious host computer.

[0080] When AEAD verification fails, node A will remove node B from its node list, add node B to the blacklist, and re-initiate [gRPC periodic call] to its TEE A.

[0081] It should be noted that if in step S2, TEE B obtains multiple privacy block write sets of different heights from the state database at once, then this step only needs to perform AEAD verification once. If the verification is successful, multiple block write sets of different heights can be accepted and processed at once, thereby achieving batch synchronization, which will greatly improve the efficiency of privacy block synchronization.

[0082] In the privacy block synchronization method based on a trusted execution environment provided in this embodiment, after key negotiation is completed, the same sm4 symmetric key will be shared within the TEE of each node. This is the source of AEAD authentication. In step S4, AEAD verification can ensure that the [privacy block information] is generated by a TEE, because only TEEs share the sm4 symmetric key, and the host computer does not have this sm4 symmetric key.

[0083] It should be noted that, for security reasons, the sm4 symmetric key shared within each node's TEE is rotated periodically. Therefore, when performing AEAD encapsulation, the version number of the sm4 symmetric key used will be used as one of the associated data.

[0084] In this embodiment, after adding a node to the blacklist, why doesn't a new node be selected as the sender to send the [privacy block synchronization request]? Instead, a [gRPC periodic call] is initiated again to its TEE A. This is because during the privacy block synchronization process, the height of the host computer may still be increasing. When returning to step S1, it will be found that the TEE is lagging behind by more blocks. Therefore, the batch synchronization mechanism can select more block heights for this request.

[0085] The privacy block synchronization method based on a trusted execution environment provided in this embodiment has the following advantages:

[0086] 1. High privacy: This embodiment clearly achieves privacy in cross-TEE device block synchronization. The plaintext information of the privacy block is only known in the TEE device isolation environment, and no host computer or external environment knows the plaintext information of the privacy block.

[0087] 2. High security: This embodiment of the invention achieves the security of privacy blocks in untrusted transmission paths.

[0088] (1) [Privacy Block Information] If the integrity is compromised during transmission (such as malicious tampering by the host computer), it will fail to pass the AEAD verification of the receiving end, thus triggering the logic of re-request.

[0089] (2) By using the authentication tag of AEAD, the receiving TEE can strongly authenticate the source of the data, ensuring that the information is generated only by a legitimate TEE with a shared symmetric key, effectively resisting forgery attacks and unauthorized data injection from malicious host computers or external nodes, and achieving strong authentication.

[0090] 3. High activity: Steps S2 and S4 effectively prevent node failures or silent attacks by malicious hosts. In extreme cases, as long as there is one honest and active node in the blockchain environment, the aforementioned privacy block synchronization mechanism can operate.

[0091] 4. Efficiency: Traditional blockchain synchronization mechanisms, due to the lack of trust between nodes, require the full execution of all transactions within a block sent by a peer node and verification of Merkle root data before accepting the block. In this embodiment, for synchronized privacy blocks, only one AEAD verification is needed; no further transaction execution is required. Once AEAD verification is successful, the privacy block can be stored in the database. Furthermore, batch synchronization is performed; therefore, only one AEAD verification is needed, and after successful verification, multiple privacy blocks can be accepted and stored in the database.

[0092] In summary, this embodiment operates on a host computer-TEE hybrid architecture, isolating the processing and storage of sensitive data within the TEE. To achieve end-to-end security across TEEs, this embodiment utilizes the TEE's built-in AEAD mechanism: the sending TEE uses a shared SM4 symmetric key to encrypt and encapsulate sensitive data for integrity, and transmits the ciphertext, authentication tag, and associated data through an untrusted host computer and P2P network; the receiving TEE only needs one AEAD verification to simultaneously check the confidentiality, integrity, and authentication of the data, and supports batch synchronization to significantly improve efficiency. It also integrates a blacklist mechanism to effectively combat malicious node tampering and silencing attacks.

[0093] Example 2

[0094] Please see Figure 6 and Figure 7This embodiment provides a privacy block synchronization system based on a trusted execution environment, including multiple blockchain nodes (a blockchain node is the basic unit constituting a distributed ledger network, a computer device running specific client software. Each node independently stores a complete or partial copy of the blockchain data, is responsible for verifying and disseminating transaction and block information, and jointly maintains the decentralized operation and data consistency of the network). Each blockchain node includes a host computer and a TEE (i.e., the system runs under a hybrid architecture of a blockchain host computer and a TEE, which divides the blockchain operation logic into two main environments: an untrusted host computer and a highly isolated TEE). The host computer and the TEE communicate through a driver layer interface and internal gRPC, such as... Figure 8 As shown.

[0095] The host computer includes a network module, a synchronization module, a gRPC client, and a state database. The network module is used for P2P network communication with other blockchain nodes. The synchronization module is used to implement the privacy block synchronization method based on a trusted execution environment provided in Embodiment 1. The gRPC client is used to initiate calls to the TEE and conduct communication. The state database is used to store the plaintext state data of the host computer.

[0096] The TEE consists of a gRPC server, a privacy contract execution engine, and a state database. The gRPC server receives gRPC calls from the host computer; the privacy contract execution engine executes privacy transactions within the TEE's isolated environment; and the state database stores privacy state data within the TEE, which is not visible to the outside world.

[0097] Among them, P2P network communication (Peer-to-Peer Network Communication): In a blockchain network, this refers to direct point-to-point data transmission and information exchange between nodes, without the need for a centralized server. gRPC (Google Remote Procedure Call): A high-performance, open-source, general-purpose RPC framework used to implement inter-process communication.

[0098] For details on the specific implementation of each module in a privacy block synchronization system based on a trusted execution environment, please refer to the above description of the limitations of the method for a privacy block synchronization system based on a trusted execution environment, which will not be repeated here.

[0099] The technical features of the above embodiments can be combined in any way (as long as there is no contradiction in the combination of these technical features). For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described; these embodiments not explicitly written should also be considered to be within the scope of this specification.

Claims

1. A privacy block synchronization method based on a trusted execution environment, characterized in that, The system includes a receiver and a sender, both of which are hybrid architectures of host computer and TEE. The receiver includes a first host computer and a first TEE, and the sender includes a second host computer and a second TEE. The method is executed by the receiver and includes: Step 1: When the block height of the first TEE lags behind the block height of the first host computer, the first host computer selects a node with good status from the node list as the sender; Step 2: The first host computer sends a privacy block synchronization request to the sender; the sender's second host computer receives the privacy block synchronization request, retrieves privacy block information from the status database of the second TEE according to the privacy block synchronization request, and returns the privacy block information to the receiver after encapsulating it with AEAD; the privacy block information includes ciphertext, AEAD authentication tag, random number, and associated data; Step 3: The first host computer receives the privacy block information returned by the sender and pushes the privacy block information to the first TEE; Step 4: The first TEE receives the privacy block information and extracts the version number from the associated data in the privacy block information through the privacy contract execution engine. It then performs AEAD verification based on the key of the version number. After the AEAD verification is successful, the ciphertext is decrypted according to a random number, and the plaintext privacy block write set is obtained. The privacy block write set is then stored in the database, thereby completing the entire privacy block synchronization process.

2. The privacy block synchronization method based on a trusted execution environment according to claim 1, characterized in that, The first host computer and the first TEE, as well as the second host computer and the second TEE, communicate through the driver layer interface and the internal gRPC.

3. The privacy block synchronization method based on a trusted execution environment according to claim 1, characterized in that, In step 2, the first host computer sends the privacy block synchronization request to the sender via a p2p network.

4. The privacy block synchronization method based on a trusted execution environment according to claim 1, characterized in that, In step 2, when the first host computer sends a privacy block synchronization request to the sender, it can request blocks of multiple heights at once.

5. The privacy block synchronization method based on a trusted execution environment according to claim 1, characterized in that, In step 2, when obtaining privacy block information from the state database of the second TEE according to the privacy block synchronization request, the specific steps include: the second host computer of the sender sends a request to the second TEE to obtain privacy block information; the second TEE receives the obtained privacy block information and calls the privacy contract execution engine; the privacy contract execution engine obtains the privacy block write set corresponding to the block height in the privacy block synchronization request from the state database of the second TEE, uses the privacy block write set as plaintext, the block height and the version number of the currently used sm4 symmetric key as associated data, generates a random number, and performs AEAD encapsulation operation using the currently used sm4 symmetric key to obtain ciphertext and AEAD authentication tag.

6. The privacy block synchronization method based on a trusted execution environment according to claim 5, characterized in that, When retrieving the privacy block write set of the corresponding height from the state database of the second TEE, multiple privacy block write sets of different heights can be retrieved at once.

7. The privacy block synchronization method based on a trusted execution environment according to claim 1, characterized in that, In step 4, if AEAD verification fails, the first host computer will remove the sender from the node list and add it to the blacklist.

8. The privacy block synchronization method based on a trusted execution environment according to claim 1, characterized in that, If the receiver does not receive the privacy block information from the sender within a preset time, the sender will be removed from the node list and added to the blacklist.

9. The privacy block synchronization method based on a trusted execution environment according to claim 7 or 8, characterized in that, Within a preset time period, the receiver will ignore the nodes in the blacklist. After the preset time period, if the status information of the nodes in the blacklist is good, they will be added back to the node list of the first host computer.

10. A privacy block synchronization system based on a trusted execution environment, characterized in that, It includes multiple blockchain nodes, each blockchain node includes a host computer and a TEE, the host computer and the TEE communicate through a driver layer interface and internal gRPC; The host computer includes a network module, a synchronization module, a gRPC client, and a state database. The network module is used to communicate with other blockchain nodes. The synchronization module is used to implement the privacy block synchronization method based on a trusted execution environment as described in any one of claims 1-9. The gRPC client is used to initiate calls to the TEE and perform communication. The state database is used to store the plaintext state data of the host computer. The TEE includes a gRPC server, a privacy contract execution engine, and a state database. The gRPC server is used to receive gRPC calls from the host computer; the privacy contract execution engine is used to execute privacy transactions within the TEE's isolated environment; and the state database is used to store privacy state data within the TEE.

Images