A blockchain smart contract privacy protection method based on trusted execution environment and assembly comparison calculation

Abstract

The application discloses a blockchain smart contract privacy protection method based on a trusted execution environment and an assembly language comparison calculation, and the method comprises the following steps: placing a smart contract execution process in a trusted execution environment, and verifying and recording a generated transaction by a blockchain. A user of the blockchain can retrieve and query data related to the smart contract and the trusted execution environment instance at any time, and submit a smart contract state update. The method embeds an assembly language comparison algorithm into the trusted execution environment, replaces a conventional high-level language comparison calculation, and thus conceals a memory access mode of a program; a contract transaction can realize contract operation management and rule definition in the executable environment, enables a contract owner to register and deregister a contract, and adds / delugs an enclave capable of running the contract; an enclave registration transaction can realize operation management and rule definition of the enclave, the method can realize trusted and compulsory execution of the blockchain smart contract, and guarantees privacy and consistent execution requirements of the smart contract.

Description

Technical Field

[0001] The present invention relates to a blockchain smart contract privacy protection method based on a trusted execution environment and assembly comparison calculation, and belongs to the technical field of blockchain. Background Art

[0002] With the continuous development of blockchain technology, its global application scenarios are becoming increasingly widespread. As the core of blockchain technology, smart contracts have played a significant role in reducing reliance on intermediaries and improving transaction efficiency. However, with the widespread use of smart contracts, the privacy challenges they face are becoming increasingly severe. All transactions and smart contract execution records in a blockchain network are publicly stored on-chain, accessible and verifiable by any network node. While this design ensures the immutability and trustworthiness of blockchain data, it also exposes sensitive data and critical business logic to the risk of theft or analysis by malicious nodes. For smart contracts, the leakage of their execution process or related data could not only infringe the privacy rights of contract participants but also lead to a range of serious consequences, including contract execution failure and financial loss, severely damaging the credibility and sustainable development of blockchain technology.

[0003] Existing solutions for protecting the privacy of blockchain smart contracts need to address the scalability of the blockchain while ensuring high security. High computational requirements and complex privacy protection protocols can limit the scalability of blockchain networks. Blockchain smart contract privacy protection solutions based on a trusted execution environment (TEE) pose the risk of leaking memory access patterns. There is an urgent need to combine the hardware-level security features of a TEE with the distributed architecture of the blockchain to more effectively ensure that transactions between nodes and within a single node can be processed in a secure and trusted environment. This can isolate and protect the smart contract execution process and prevent malicious operating system inference attacks on the smart contract execution process.

[0004] After preliminary search, the relevant prior art is as follows:

[0005] Invention patent CN110245506B describes a blockchain-based smart contract management method and device, which manages the calls of smart contracts on blockchain node devices equipped with a trusted execution environment. If the smart contract is not marked as managed, its encrypted contract code can be decrypted and executed in the trusted execution environment of the node device, and the execution result is encrypted and stored on the blockchain. This method protects the privacy of smart contracts while also allowing content supervision of specific smart contracts, achieving a balance between privacy protection and effective management. Although the use of a trusted execution environment in this patent improves the execution security of smart contracts, these environments may have security vulnerabilities, such as memory access pattern leaks, which may threaten the privacy of data. As the blockchain network expands, the complexity of managing and storing decryption keys may increase, and more complex management mechanisms may be required to track and update regulatory rules. The shortcomings correspond to the purpose of the present invention.

[0006] Invention patent CN110520884B describes an off-chain smart contract service method based on a trusted execution environment (TEE), designed to provide privacy-preserving cross-chain data operations. A smart contract service provider, external to the target blockchain network, receives cross-chain data operation requests from clients, executes computational logic within the TEE, generates results, and then returns them to the client. This method involves a data access service provider and may involve verifying that all parties involved in the TEE are included to ensure security. Furthermore, the results may be signed with a private key, which the client can decrypt using a public key. The system is applicable to cloud servers, and cross-chain data may originate from multiple blockchain networks. Ensuring that only authorized participants can access and process data in cross-chain data operations is crucial. However, the patent text does not address how to implement access control and permission management for data. This may lead to the risk of unauthorized participants gaining access to sensitive information. The patent also fails to discuss in detail how to prevent malicious attacks from impacting cross-chain data operations. This leaves the service vulnerable to potential security threats and risks. These shortcomings are outweighed by the objectives of the present invention. Summary of the Invention

[0007] The present application is to solve the problem of the risk of blockchain smart contract being stolen or analyzed by malicious nodes. Although the current technical solutions provide solutions for blockchain smart contract privacy protection, such as executing the smart contract in a trusted execution environment, the problem of memory access pattern leakage during the execution of the smart contract has not been solved. The present application proposes to execute the smart contract in a secure enclave of a trusted execution environment. The blockchain verifies and records the generated transactions. The smart contract party retrieves and checks the data related to the smart contract and the enclave instance, serializes and submits the smart contract state update. By embedding the assembly language comparison algorithm into the trusted execution environment and replacing the comparison calculation in the trusted execution environment, the inference attack of the smart contract execution process by the malicious operating system is effectively prevented.

[0008] To solve the above technical problems, the present application provides a blockchain smart contract privacy protection method based on trusted execution environment and assembly comparison calculation, comprising the following steps:

[0009] Step 1: Establish a secure execution environment

[0010] On the blockchain, the smart contract is registered and set to execute in the contract enclave through the contract registration transaction. The enclave service provides a secure execution environment where the contract is isolated and runs to ensure that the data is not disturbed by external interference.

[0011] Step 2: Encryption and verification

[0012] The configuration service provides encryption keys to ensure the security of the contract state when stored externally. The contract owner obtains these keys through configuration requests. At the same time, the trusted execution environment proof service ensures the security and trustworthiness of the execution environment through verification reports and enclave proofs.

[0013] Step 3: Secure execution and protection

[0014] When executing the smart contract, use assembly language comparison calculation to call comparison operations to prevent memory access pattern leakage. The user obtains the latest state and enclave information, calls the contract method for operation, and obtains the execution result in a secure environment.

[0015] Step 4: Result verification and record

[0016] The user performs register state conversion on the execution result and submits it to the blockchain after signing. The blockchain verifies and records these results to ensure the integrity and traceability of all transactions.

[0017] Further, the blockchain includes contract transactions, enclave transactions, coordination and submission log transactions.

[0018] Contract transactions implement the operations and rules governing a contract. Specifically, they enable contract owners to register and deregister contracts, as well as add and remove enclaves in which contracts can run. Furthermore, contract owners use contract transactions to specify a list of configured services for the contract. Smart contract owners ensure the security and trustworthiness of their contracts through interaction with the Trusted Execution Environment enclave.

[0019] Enclave transactions implement the operations and rules for managing enclaves. Available operations include registering, updating, and deregistering enclaves. Enclave services must adhere to certain rules, such as providing the enclave owner, the enclave's public key, and the enclave's credentials, which are verified by the Trusted Execution Environment (TEE) Attestation Service. This information must be verified before submissions can be accepted.

[0020] The coordination and commit log transactions distinguish transaction ordering and semantics, allowing dependencies between state update transactions to be expressed, and constructing a dependency graph using off-chain logic and on-chain contract identifiers. Validators enforce dependencies by rejecting dependencies on uncommitted transactions, allowing serial contract state updates and concurrent execution that depends on the state of other contracts. The legitimacy of updates is guaranteed by digital signatures within the contract enclave.

[0021] Furthermore, the contract transaction functions are as follows:

[0022] Contract transactions implement the operations and rules governing a contract. Specifically, they enable contract owners to register and deregister contracts, as well as add and remove enclaves in which contracts can run. Furthermore, contract owners use contract transactions to specify a list of configured services for the contract. Smart contract owners ensure the security and trustworthiness of their contracts through interaction with the Trusted Execution Environment enclave.

[0023] Furthermore, the enclave transaction functions are as follows:

[0024] Enclave transactions implement the operations and rules for managing enclaves. Available operations include registering, updating, and deregistering enclaves. Enclave services must adhere to certain rules, such as providing the enclave owner, the enclave's public key, and the enclave's attestation, which is verified by the Trusted Execution Environment (TEE) Attestation Service. This information must be verified before submissions can be accepted.

[0025] Furthermore, the coordination and submission of log transactions functions are as follows:

[0026] Coordination and commit log transactions distinguish transaction ordering and semantics, allowing dependencies between state update transactions to be expressed, and constructing a dependency graph using off-chain logic and on-chain contract identifiers. Validators enforce dependencies by rejecting dependencies on uncommitted transactions, allowing serial contract state updates and concurrent execution that depends on the state of other contracts. The legitimacy of updates is guaranteed by digital signatures within the contract enclave.

[0027] Off-chain logic refers to calculations or processing performed outside of the blockchain network. Unlike on-chain logic, off-chain logic is not executed directly on the blockchain but rather processed in an external system. This approach can be used to reduce on-chain computational load, improve efficiency, and handle complex logic. Common off-chain logic includes:

[0028] 1) Data preprocessing: Cleaning and formatting the data before uploading it to the blockchain.

[0029] 2) Complex computing: Perform complex computing tasks outside the blockchain and then record the results on the blockchain.

[0030] 3) State management: Manage and track changes in system status, rather than recording every change on the blockchain.

[0031] Building a dependency graph using on-chain contract identifiers refers to representing and constructing a dependency graph between different contracts or transactions in a blockchain system using smart contract identifiers. Specifically, a contract identifier is a unique identifier for each smart contract on the blockchain, typically an address. A dependency graph is a graph structure where nodes represent smart contracts or transactions, and edges represent dependencies. Dependencies can be sequential dependencies between transactions or dependencies on state updates.

[0032] Furthermore, the contract enclave includes a contract interpreter, a smart contract, and a contract status.

[0033] Similar to the Ethereum Virtual Machine, the contract interpreter executes the contract code registered by the contract owner on the blockchain. The contract interpreter is not tied to a specific smart contract, so the contract enclave can run any contract written in the interpreter's language. Since the contract interpreter runs within the Trusted Execution Environment (TEE) enclave, its implementation requires several features: (i) Contract code sandboxing. This prevents untrusted third parties from implementing malicious contracts and tampering with the rest of the enclave and the enclave service platform. (ii) A small code footprint / trusted computing base. This reduces code complexity, simplifying code audits. (iii) A unique contract representation. This allows participants to easily verify the contract. Furthermore, all participants can agree on the same copy, which can be identified by a cryptographic hash on the blockchain, avoiding the generation of multiple documents due to non-deterministic compilation. Finally, it allows for easy authentication and execution of the agreed-upon copy within the enclave. (iv) Efficient contract state management. This allows contracts to handle state without having to pre-load it into the enclave.

[0034] A method for accessing and updating data in a contract state using a smart contract. Since parties need to agree before using a smart contract in the method, it is desirable that they can communicate with each other offline so as to share the smart contract code off-chain. So the smart contract is not necessarily public. Its execution is designed to happen locally within a trusted execution environment enclave of a selected enclave service.

[0035] A smart contract state indicates private data associated with a particular contract. At contract runtime, the contract can access the clear state managed by the contract interpreter. In other cases, the contract state is encrypted when stored outside the contract enclave. At the first invocation of a contract method, the contract interpreter initializes an empty contract state for the contract. In subsequent invocations, the contract interpreter reads or modifies the contract state according to the logic implemented by the contract. Because the trusted execution environment maintains the confidentiality of the data, the contract interpreter can access the contract state in clear. The contract enclave decrypts / encrypts the contract state before / after the contract needs the data, which is performed using keys specific to the contract.

[0036] A configuration service responds to a request from a contract owner to configure keys for a contract enclave. These keys are eventually used to encrypt the contract state. Only the configured contract enclave can access all the keys, so it can decrypt the contract state. The configuration protocol is mediated by the contract owner. The configuration service participates in the protocol as long as it can successfully verify the registration of the contract and enclave on the blockchain. The protocol can be implemented on a generic interface, allowing it to be customized according to specific application / deployment scenarios. The currently implemented protocol allows the configuration service to generate secret keys and guarantees security as long as one of the participating configuration services is honest. The purpose of using the configuration service is to make the encryption of the smart contract state independent of (i) the enclave (ii) the enclave service. Among them, the enclave can ensure that the contract enclave has statelessness in terms of contracts, it only needs the contract and the contract state to execute method calls, which can solve the problem of moving state between two enclaves running on different platforms. The enclave service is not trusted by other parties, and once the enclave is terminated and the transaction is committed to the ledger, the enclave service cannot be trusted to persist key enclave data, such as sealed storage and encrypted state. This will make it vulnerable to serious denial-of-service attacks. The denial-of-service attack problem is strictly related to the contract state, not to any enclave data in the sealed storage.

[0037] The assembly comparison module first allocates sufficient memory within the Trusted Execution Environment (TEE) enclave to store the data to be compared and any temporary data generated during algorithm execution. It also initializes state variables required for algorithm execution, such as error flags and counters. The data items to be compared are then loaded from external memory into the enclave's protected memory. This can be accomplished by calling interfaces provided by the Trusted Execution Environment (TEE) SDK. The integrity and validity of the data loaded into the enclave can be verified by calculating a hash value and comparing it with the expected value, or by using methods such as digital signatures. If data verification fails, an error is logged and the algorithm exits. Next, the appropriate data type processing logic is selected based on the input data type. Complex data types may require conversion to a format that is easier to compare, such as numeric or binary representations. This involves operations such as string parsing and encoding conversion. The appropriate comparison instruction is then selected based on the input comparison type. In x86 assembly language, this is typically implemented using instructions such as CMP, JL, JG, and JE. The data to be compared is then loaded into registers, and the comparison instruction is executed. The comparison result is typically indicated by setting flags such as ZF, SF, and OF. Next, the comparison result is obtained based on the flag status after the comparison instruction is executed. For example, if the ZF flag is set to 0, it indicates that the two data are equal; if the SF and OF flags meet certain conditions, it means that one number is greater than the other, and so on. Finally, the corresponding subsequent operations are performed based on the comparison result, including updating status, triggering events, and calling other functions.

[0038] Furthermore, the transaction execution protection includes submitting a transaction request, executing a transaction, and responding to a transaction.

[0039] The method to submit a transaction request is as follows:

[0040] (1) Generate a one-time symmetric key (SEK) using the Advanced Encryption Standard-Counter Mode algorithm. AES-GCM (Advanced Encryption Standard-Galois / Counter Mode) is a symmetric encryption algorithm that combines the Advanced Encryption Standard (AES) and Galois / Counter Mode (GCM) to provide encryption and data integrity verification, ensuring data confidentiality and integrity.

[0041] (2) Use the generated SEK to encrypt the transaction request data. This ensures that only entities with the corresponding decryption key can access the original data content.

[0042] (3) Calculate the SHA256 hash value of the original transaction data. This step is used to verify the integrity of the data later, ensuring that the data has not been tampered with during transmission. The SEK is then encrypted using the enclave public key, obtained from the Trusted Execution Environment enclave (a secure execution environment). The SEK is encrypted using the enclave's RSA component's optimal asymmetric encryption padding public key.

[0043] (4) The private key is then used to sign the 256-bit secure hash value of the transaction data. This step provides verification of the data’s origin and proof of data integrity. The signature confirms that the data was sent by the user holding the corresponding private key and has not been tampered with.

[0044] (5) The encrypted transaction data, encrypted SEK, and encrypted hash value are combined into an encrypted transaction request object. The encrypted transaction request contains all the necessary elements for verification and decryption at the receiving end, while the signature is used to verify the legitimacy of the transaction and the integrity of the data. Finally, the algorithm returns the encrypted transaction request data and signature.

[0045] The transaction execution method is as follows:

[0046] (1) Use the RSA-OAEP algorithm and the enclave private key to decrypt the encrypted SEK to be passed in. The enclave private key is generated and stored in a secure environment and cannot be accessed externally, thus ensuring the security of the key.

[0047] (2) Decrypt the transaction request data. The transaction request data is encrypted with AES-GCM-256 using the SEK to ensure data security during transmission. The data is decrypted using the SEK within the enclave to obtain the original transaction content.

[0048] (3) Calculate the SHA256 hash value of the decrypted transaction data to verify the integrity of the data. Decrypt the incoming encrypted hash value and compare it with the calculated hash value. If they are inconsistent, it means that the data has been tampered with during transmission or processing.

[0049] (4) Return an error if the hash value does not match. If the hash value does not match, an error message is returned and the processing flow is interrupted. This ensures that only data that has passed the verification is further processed.

[0050] (5) Verify the digital signature. If a signature is provided, use the requester's public key to verify the authenticity and validity of the signature. This step ensures that the sender of the data is known and trusted, and that the data has not been modified since it was signed.

[0051] (6) Execute the corresponding business logic based on the decrypted transaction data, including reading and writing databases, executing computing tasks, etc.

[0052] (7) Use the same SEK to encrypt the processing results to ensure the security of the response data when it is returned to the requester.

[0053] (8) Calculate the SHA256 hash value of the response data to provide verification for the integrity of the response data.

[0054] (9) The encrypted response data, the signature of the response hash value, and the hash value itself are returned to the requester. In this way, the requester can verify the integrity and authenticity of the response.

[0055] The transaction response method is as follows:

[0056] (1) Retrieving the public key of a trusted computing node involves obtaining the public key from a database, configuration file, or key management service.

[0057] (2) Retrieve the SEK from the requesting party’s local storage. This ensures that only the two parties who know the key can access the transmitted data content.

[0058] (3) The signature of the transaction response is verified using the retrieved public key. This typically involves using a public key cryptography algorithm such as RSA or the Elliptic Curve Digital Signature Algorithm (ECDSA) to confirm that the signature matches the encrypted data. If signature verification fails, an error is returned, indicating that the data may have been tampered with in transit or that the signing key is incorrect.

[0059] (4) Decrypt the encrypted response data using the SEK retrieved in (2). Decryption usually uses a symmetric encryption algorithm (such as AES-GCM), which is fast and secure and suitable for large-scale data processing.

[0060] (5) Return the decrypted data and signature verification result. If the signature verification succeeds, the requester can trust the decrypted data and proceed accordingly. If the verification fails, the requester should consider taking security measures, such as logging the security incident or refusing data processing.

[0061] A blockchain smart contract privacy protection system based on a trusted execution environment and assembly comparison calculation is used to implement the smart contract privacy protection method, including two modules: blockchain and contract enclave.

[0062] The blockchain module is used to track user-submitted blockchain transactions (hereinafter referred to as "transactions"), dependencies, and registered / updated / deregistered enclaves and smart contracts;

[0063] The Contract Enclave module contains a Trusted Execution Environment enclave with a smart contract interpreter, capable of responding to registration / deregistration in enclave registration transactions, adding / removing from the list of enclaves authorized to execute a specific smart contract in contract registration transactions, and generating execution results that are submitted to coordination and commit log transactions for verification.

[0064] Compared to existing technologies, the present invention offers the following advantages: The smart contract execution process is placed within a secure enclave within a trusted execution environment (TEE), ensuring data access policies are enforced and ensuring data confidentiality and execution integrity. The blockchain verifies and records generated transactions. Smart contract parties retrieve and inspect data related to the smart contract and enclave instance, serializing and submitting smart contract status updates. By embedding an assembly language comparison algorithm within the TEE, replacing the comparison calculations within the TEE, this effectively prevents memory access pattern leaks and malicious operating system attacks against the smart contract execution process. Furthermore, the present invention offers excellent scalability while maintaining confidentiality, combining privacy with high performance, and possesses high practicality. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] The drawings described herein are used to provide a further understanding of this specification and constitute a part of this specification. The exemplary embodiments and descriptions of this specification are used to explain this specification and do not constitute an improper limitation of this specification. In the drawings:

[0066] Figure 1 The overall architecture of the smart contract privacy protection method based on trusted execution environment and assembly comparison calculation is presented.

[0067] Figure 2 This is a comparative diagram of blockchain DAPP assembly languages ​​that can avoid memory access leakage attacks, as shown in an exemplary embodiment;

[0068] Figure 3 This is a process diagram of a contract transaction method shown in an exemplary embodiment;

[0069] Figure 4 is a schematic diagram illustrating the process of enclave registration, update, and cancellation according to an exemplary embodiment;

[0070] Figure 5 FIG. 1 is a schematic diagram showing a process of coordinating and submitting log transactions according to an exemplary embodiment. DETAILED DESCRIPTION

[0071] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative work should fall within the scope of protection of this specification.

[0072] It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments, and multiple steps described in this specification may be combined into a single step for description in other embodiments.

[0073] The technical solutions provided by the embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0074] Example:

[0075] Figure 1 This paper presents the overall architecture of a smart contract privacy-preserving approach based on a trusted execution environment (TEE) and assembly-based comparative computing. This approach allows mutually untrusted individuals and organizations to access and update private data using pre-agreed policies. Specifically, the approach implements these policies within the smart contract and uses a trusted execution environment (TEE) to bind them to data. This data constitutes the smart contract state. Any state update is the result of a smart contract method call. Method calls are triggered by users and executed by the smart contract interpreter. Specifically, the user retrieves the latest data from the ledger and requests a call to the enclave service, which hosts the trusted execution environment (TEE) enclave. The contract interpreter executes the smart contract code on the input smart contract state, resulting in a state transition and a new state. This process occurs within the TEE enclave, protecting the integrity and confidentiality of the smart contract code and data. The smart contract state and code are stored in encrypted form outside the enclave's trust boundary. The final result is returned to the user. The user ultimately submits a transaction regarding the updated state to the blockchain, which is verified and recorded for validity and subsequent auditability. The enclave service registers the contract enclave on the blockchain. This enclave is provided as a smart contract execution-as-a-service business model. Registration includes an enclave attestation verification step using the Trusted Execution Environment Attestation Service, which verifies the enclave's hardware root of trust. The enclave service then commits the registration transaction to the ledger along with the enclave's verification report.

[0076] Although smart contract execution occurs off-chain, the owner registers the smart contract on the blockchain and authorizes its execution through the enclave service. Registration occurs on the blockchain, while execution authorization is achieved through key configuration. This is achieved through a set of configuration services that provide cryptographic services for encrypting the state of registered enclaves. The selected configuration service and the actual configured enclave are ultimately exposed on the blockchain in the contract transaction. The blockchain ensures a single authoritative instance and log for the method. Proof of operations and the identities of the involved parties, namely cryptographic signatures, are publicly available for end-user verification and trust. Furthermore, the blockchain helps ensure the atomicity of updates between methods and validates dependencies between transactions. Method state transitions cannot be trusted until the associated transactions are submitted to and accepted by the blockchain.

[0077] Assembly language comparison calculations hide the program's memory access patterns. By using comparison operations written in assembly language and translating the calculation process directly into CPU register operations, this prevents potential memory access pattern leaks in algorithms implemented in conventional high-level languages. Regardless of how the input data changes, the assembly language comparison module executes the same code path, preventing changes in memory access patterns due to input variations, thereby improving program security and privacy.

[0078] Figure 2 This is a diagram illustrating an assembly language comparison for blockchain DAPPs that can prevent memory access leak attacks, as an example embodiment. Simple execution of high-level languages ​​often changes memory access patterns based on input data. For example, "IF statements" are a common form of memory access pattern leakage. Assuming an attacker can always observe calls within and outside the Trusted Execution Environment enclave, but cannot observe internal CPU register operations, the attacker can record the execution time of these calls and all resource accesses. Conventional smart contract algorithms that do not rely on assembly language comparison calculations are essentially based on comparison calculations and use numerous "IF statements" during the declaration phase to determine maximum values, which can lead to memory access pattern leakage.

[0079] Assembly language comparison calculations follow the exact same code path for any data access, and their memory access patterns are independent of the input values, operating instead on CPU registers. Replace the "IF" statement with an assembly language comparison calculation, assign the comparison values ​​to separate registers, and then set a flag based on the comparison operation you want to test, allowing you to determine the highest value. Exit the assembly language code using the binary value stored in the flag bit, and then perform a simple arithmetic switch. If the flag bit is unset (i.e., equal to 0), the value is retained, indicating that the new value is not greater than the current maximum. If the flag bit is set (i.e., equal to 1), the value is changed to the new bid, indicating that the new value is greater than the current maximum.

[0080] We exit from the assembly code and use the binary value stored in flags. We then perform a simple arithmetic switch. If the flag is not set, i.e. value = 0, we keep the value, indicating that the new value is not greater than the current maximum. If the flag is set, the value = 1, we change the value to the new bid, indicating that the new value is indeed greater than the current maximum.

[0081] Figure 3 This document illustrates the operational process of a smart contract transaction. During the contract registration phase, the contract owner submits the contract code and configuration to the Trusted Execution Environment (TEE) enclave. The TEE enclave performs internal initialization and verification, then sends a registration request containing the TEE signature to the blockchain network. The blockchain network distributes the registration request for verification. Validation nodes apply a consensus mechanism to validate the request and record the registration transaction on the blockchain, completing the contract registration. During the contract update and cancellation phase, the contract owner submits a request through the TEE enclave. After receiving the request, the TEE enclave verifies the validity of the request and returns a successful verification message to the owner. Based on this information, the owner then submits an update or cancellation transaction to the blockchain network, ensuring that contract updates and cancellations are performed securely and controllably. During the contract call phase, the owner initiates a call request to the TEE enclave. After verifying the request, the TEE enclave constructs and executes the call transaction. After the blockchain network executes the contract logic, it returns the execution results to the trusted execution environment enclave, which then provides them to the contract owner, ensuring the security of contract calls and the integrity of data.

[0082] Figure 4 The operational process of an enclave transaction is demonstrated. In an enclave registration transaction, the owner submits a request containing a unique identifier, public key, and digital signature through the consortium blockchain. Verifiers use the public key to verify the validity of the signature, ensuring the requester is legitimate. They also compare the message digest using a hash function to ensure the information has not been tampered with. Once verified, the registration information is stored in a structured format on the blockchain, ensuring information security. In an enclave update transaction, the owner or authorized person submits a change request, which undergoes identity authentication, permission checks, and information consistency and content verification. Only when the request meets the requirements and passes verification is the updated information recorded on the blockchain, enabling real-time updates. In an enclave deregistration transaction, the relevant party submits a deregistration request and provides a reason. Verifiers verify identity and permissions, review the deregistration reason, execute the deregistration decision, and update the enclave status to deregistered. This change is recorded on the blockchain for easy subsequent querying.

[0083] Figure 5This article demonstrates the operational process for coordinating and submitting log transactions. The client first submits a transaction containing a smart contract call request to a consortium chain node. The node analyzes the dependencies between these transactions and constructs a dependency graph to ensure the correctness of state updates. Next, the node bundles the transactions into blocks based on the dependency graph, sorting them by priority and type. The node then verifies the legitimacy and integrity of each transaction and digitally signs it with its private key. The node then broadcasts the bundled transaction to other consensus nodes, which verify its legitimacy and signature and check its dependencies. After the transaction passes consensus verification, the node records it in its local log and regularly synchronizes the log to ensure data consistency. When executing smart contracts in a trusted execution environment enclave, the node ensures data privacy and integrity. After execution is complete, the node verifies the legitimacy of the state update and broadcasts the result. When sufficient nodes reach consensus on the result, the transaction is confirmed. Finally, the client can query the chain status or receive notifications to learn about the latest transaction status. This entire process ensures the secure and efficient operation of consortium chain smart contracts based on a trusted execution environment.

[0084] It should be noted that the above embodiments are not intended to limit the scope of protection of the present invention, and equivalent changes or substitutions made on the basis of the above technical solutions fall within the scope of protection of the claims of the present invention.

Claims

1. A blockchain smart contract privacy protection method based on a trusted execution environment and assembly comparison calculation, characterized in that: The method comprises the following steps: Step 1: Establish a secure execution environment, On the blockchain, through the contract registration transaction, the smart contract is registered and set to execute in the contract enclave. The enclave service provides a secure execution environment where the contract is run in isolation, ensuring that the data is not interfered with by the outside world. Step 2: Encryption and verification, The configuration service provides encryption keys to ensure that the contract state remains secure when stored externally. Contract owners obtain these keys through configuration requests. At the same time, the trusted execution environment attestation service ensures the security and trustworthiness of the execution environment through verification reports and enclave attestations. Step 3: Safe execution and protection, When executing smart contracts, assembly language comparison calculations are used to call comparison operations to prevent memory access pattern leaks. Users can obtain the latest status and enclave information, call contract methods to perform operations, and obtain execution results in a secure environment. Step 4: Verify and record the results, The user converts the execution results into register states and submits them to the blockchain after signing. The blockchain verifies and records these results to ensure the integrity and traceability of all transactions.

2. The blockchain smart contract privacy protection method based on trusted execution environment and assembly comparison calculation according to claim 1 is characterized in that: The blockchain module used in step 1 is as follows: tracking submitted transactions, dependencies, registered / updated / deregistered enclaves and smart contracts, including: Contract transactions implement the operations and rules for managing contracts. Contract owners can register and deregister contracts, add / delete enclaves where contracts can run, and use contract transactions to specify a list of configuration services for a contract. Enclave transactions implement operations and rules for managing enclaves. Available operations include registering, updating, and deregistering enclaves. Coordination and commit log transactions are used to distinguish transaction ordering and semantics, allowing the expression of dependencies between state update transactions, and building a dependency graph with off-chain logic and on-chain contract identifiers.

3. The blockchain smart contract privacy protection method based on trusted execution environment and assembly comparison calculation according to claim 1 is characterized in that: The contract enclave module used in step 1 is as follows: a trusted execution environment enclave with a smart contract interpreter, capable of responding to enclave registration / deregistration in enclave transactions, adding / removing from the list of enclaves authorized to execute a specific contract in contract transactions, and generating execution results submitted to coordination and commit log transactions for verification, including: The smart contract interpreter executes the contract code registered by the contract owner on the blockchain. The contract interpreter is not bound to a specific contract and can run any contract written in the interpreter language. Smart contracts are used to access and update data in the smart contract state. Smart contracts do not have to be public, and their execution is designed to occur locally within the selected trusted execution environment. The contract state indicates the private data associated with a specific contract. When the smart contract is running, the smart contract accesses the plaintext state managed by the contract interpreter. Otherwise, the contract state is encrypted when stored outside the contract enclave.

4. The blockchain smart contract privacy protection method based on trusted execution environment and assembly comparison calculation according to claim 1 is characterized in that: The assembly language comparison calculation in step 3 is as follows: The comparison operation written in assembly language hides the program's memory access pattern and directly converts the calculation process into CPU register operations, avoiding the memory access pattern leakage that may be encountered in conventional high-level language implementation algorithms. This includes: Memory space allocation and state variable initialization: Allocate sufficient memory space in the enclave to store data and temporary data, and initialize the state variables required by the algorithm; Load data and verify integrity. External data is loaded into protected memory and the data integrity and validity are verified. Comparison algorithm preprocessing, select the corresponding processing logic according to the data type, and select the corresponding comparison instruction according to the comparison type; Data loading and comparison: load the data to be compared into the register, execute the comparison instruction, and indicate the comparison result by setting the flag bit; Execute corresponding subsequent operations based on the comparison results, including status updates, event triggering, and calling other functions.

5. A blockchain smart contract privacy protection system based on a trusted execution environment and assembly comparison calculation, characterized in that: A method for protecting smart contract privacy according to any one of claims 1 to 4, characterized in that it comprises two modules: a blockchain and a contract enclave. The blockchain module is used to track user-submitted blockchain transactions, dependencies, and registered / updated / deregistered enclaves and smart contracts; The Contract Enclave module contains a Trusted Execution Environment enclave with a smart contract interpreter, capable of responding to registration / deregistration in enclave registration transactions, adding / removing from the list of enclaves authorized to execute a specific smart contract in contract registration transactions, and generating execution results that are submitted to coordination and commit log transactions for verification.

Images