Smart contract privacy protection method and device

Abstract

The invention discloses an intelligent contract privacy protection method and device, and the method is applied to a client, and comprises the steps: creating a security isolation environment through trusted hardware during starting, and carrying out the remote certification, and then carrying out the registration to a block chain node; initiating a balance withdrawal transaction request to the smart contract, so that the smart contract returns second proof information to the security isolation environment after executing chain balance destruction on the block chain account address of the client; after the second certification information is verified in the security isolation environment, updating and encrypting a local available balance to generate third certification information; and receiving a transfer transaction request of a user, and sending the transfer transaction request to the smart contract, so that the smart contract updates the on-chain balance ciphertext of the sender and the receiver after the transfer transaction request is verified based on the registration information. The method has the advantages of high expandability, privacy and deployment flexibility.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method and apparatus for protecting the privacy of smart contracts. Background Technology

[0002] This section is intended to provide background or context for the embodiments of the invention set forth in the claims. The description herein is not an admission that it is prior art simply because it is included in this section.

[0003] Blockchain is a decentralized distributed ledger technology that ensures the security and consistency of data records through encryption mechanisms and consensus algorithms. This technology encapsulates transaction information into blocks and links them in chronological order to form an immutable ledger history. Because each node maintains a complete copy of the ledger, and all data writes require network-wide consensus, blockchain demonstrates significant advantages in achieving data transparency, tamper resistance, and traceability, and is widely used in smart contracts, supply chain management, and many other fields.

[0004] Smart contracts are automated execution programs deployed on a blockchain network that allow transactions to be executed without the supervision of a trusted third party. As distributed applications on the blockchain, smart contracts present privacy issues during execution, as the contract code and state are transparent to all participants, potentially exposing sensitive information.

[0005] With the widespread adoption of smart contracts, privacy has become a significant research area. Privacy issues in smart contracts broadly refer to problems such as contract state privacy, anonymity of transaction participants, and privacy of contract instructions. The transparency of blockchain data and the privacy protection of smart contracts present an inherent contradiction. Specifically, the execution process and results of a smart contract can be observed by all nodes in the blockchain, meaning any unauthorized user can access relevant information. This transparency not only exposes the identities and data in the transaction but also affects the applicability of its applications.

[0006] Currently, privacy-preserving smart contracts are mainly implemented through four types of technologies: trusted hardware (including but not limited to trusted execution environments (TEEs), trusted platform modules (TPMs), and secure elements), zero-knowledge proofs (ZKPs), secure multi-party computation (MPC), and homomorphic encryption (HE). TEEs rely on hardware to provide an isolated execution environment, offering superior performance but suffering from issues such as centralized trust roots and vulnerability to side-channel attacks; ZKPs verify the correctness of computations without revealing data, providing strong privacy but incurring high computational costs and poor adaptability; MPCs distribute computation among multiple participants to ensure privacy, offering high security but incurring significant communication overhead and complex deployment; HEs support direct computation on ciphertext, providing strong privacy capabilities but are inefficient and difficult to support complex contract logic.

[0007] To overcome the limitations of a single technology path in terms of performance, versatility, and security, there is a need for a smart contract privacy protection solution that can simultaneously meet the above requirements to support anonymous transaction operations in smart contracts. Summary of the Invention

[0008] This invention provides a smart contract privacy protection method applied to a client, which features high scalability, privacy, and deployment flexibility, including:

[0009] Upon startup, a secure and isolated environment is created through trusted hardware, a remote verification process is initiated with the remote certification center, and registration is completed with the blockchain node based on the first verification information received to obtain registration information.

[0010] A balance withdrawal transaction request is initiated to the smart contract deployed on the blockchain node, so that the smart contract performs on-chain balance destruction on the blockchain account address of the client and then returns second proof information to the client's secure isolation environment. The second proof information is used to prove that the destruction is completed.

[0011] After verifying the second proof information in a secure isolated environment, the local available balance is updated based on the second proof information. The updated local available balance is then encrypted to obtain the local available balance ciphertext, and a third proof information is generated. The third proof information is used to prove the correctness of the local available balance update.

[0012] Receive user transfer transaction requests, the transfer transaction requests including local available balance ciphertext and third-party proof information;

[0013] The transfer transaction request is submitted to the smart contract, so that after the smart contract verifies the transfer transaction request based on the registration information, it updates the on-chain balance ciphertext of the sender and the receiver under ciphertext conditions, wherein the sender is the client.

[0014] This invention provides another method for protecting the privacy of smart contracts, applied to smart contracts deployed on blockchain nodes. This method offers high scalability, privacy, and deployment flexibility, including:

[0015] Upon receiving a balance withdrawal transaction request initiated by the client, the client creates a secure and isolated environment through trusted hardware upon startup, initiates a remote verification process with the remote certification center, and registers with the blockchain node based on the first verification information received to obtain registration information.

[0016] The on-chain balance of the client's blockchain account address is destroyed, and a second proof information is returned to the client's secure isolation environment. After the client verifies the second proof information in the secure isolation environment, it updates its local available balance according to the second proof information, encrypts the updated local available balance to obtain the local available balance ciphertext, and generates a third proof information. The second proof information is used to prove that the destruction is complete, and the third proof information is used to prove the correctness of the local available balance update.

[0017] Receive a transfer transaction request submitted by the client, the transfer transaction request including the local available balance ciphertext and third-party proof information;

[0018] The transfer transaction request is verified based on the registration information. After successful verification, the on-chain balance ciphertext of the sender and receiver is updated under ciphertext conditions. The sender is the client.

[0019] This invention provides a smart contract privacy protection device applied to a client, which features high scalability, privacy, and deployment flexibility, including:

[0020] The initialization module is used to create a secure and isolated environment through trusted hardware at startup, initiate a remote proof process to the remote certification center, and register with the blockchain node based on the first proof information received to obtain registration information.

[0021] The balance withdrawal module is used to initiate a balance withdrawal transaction request to the smart contract deployed on the blockchain node. This causes the smart contract to destroy the on-chain balance of the client's blockchain account address and then return a second proof information to the client's secure isolation environment. This second proof information proves that the destruction is complete. After verifying the second proof information in the secure isolation environment, the module updates the local available balance based on the second proof information, encrypts the updated local available balance to obtain the local available balance ciphertext, and generates a third proof information. This third proof information proves the correctness of the local available balance update.

[0022] The transfer module is used to receive user transfer transaction requests, which include local available balance ciphertext and third-party proof information; the transfer transaction request is submitted to the smart contract, so that after the smart contract verifies the transfer transaction request based on the registration information, it updates the on-chain balance ciphertext of the sender and the receiver under the ciphertext condition, where the sender is the client.

[0023] This invention provides a smart contract privacy protection device for smart contracts deployed on blockchain nodes. It offers high scalability, privacy, and deployment flexibility, and includes:

[0024] The first receiving module is used to receive a balance withdrawal transaction request initiated by the client. The client creates a secure isolation environment through trusted hardware when it starts up, initiates a remote certification process to the remote certification center, and registers with the blockchain node based on the first certification information received to obtain registration information.

[0025] The balance destruction module is used to destroy the on-chain balance of the client's blockchain account address, return second proof information to the client's secure isolation environment, so that after the client verifies the second proof information in the secure isolation environment, it updates the local available balance according to the second proof information, encrypts the updated local available balance to obtain the local available balance ciphertext, and generates third proof information; the second proof information is used to prove that the destruction is completed, and the third proof information is used to prove the correctness of the local available balance update;

[0026] The second receiving module is used to receive a transfer transaction request submitted by the client, the transfer transaction request including the local available balance ciphertext and third proof information;

[0027] The balance ciphertext update module is used to verify transfer transaction requests based on registration information. After successful verification, it updates the on-chain balance ciphertext of the sender and receiver under ciphertext conditions. The sender is the client.

[0028] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-described smart contract privacy protection method.

[0029] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described smart contract privacy protection method.

[0030] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described smart contract privacy protection method.

[0031] The smart contract privacy protection method and apparatus proposed in this invention combine the execution isolation advantages of trusted hardware with the strong privacy of homomorphic encryption in on-chain data encryption processing, realizing a fusion mechanism of off-chain trust in contract execution and on-chain balance management encryption security. Compared with traditional pure trusted hardware or pure cryptographic protocols (such as zero-knowledge proofs or secure multi-party computation) schemes, the hybrid architecture of this scheme has higher scalability, privacy, and deployment flexibility. On-chain smart contract execution is achieved through three stages: In the initialization stage, the client creates a secure isolation environment and completes remote proof; in the balance withdrawal stage, the smart contract destroys the on-chain balance of the client's blockchain account address and generates second proof information. After verification by trusted hardware, the off-chain balance (i.e., the client's local available balance) is updated synchronously. The updated local available balance is encrypted to obtain the local available balance ciphertext and generates third proof information; in the transfer stage, trusted hardware sends a transfer transaction request to the smart contract. The smart contract verifies the third proof information and updates the on-chain balance ciphertext of the sender and receiver under the ciphertext condition. The sender is the client. The entire process ensures transaction privacy and on-chain verifiability, building a highly secure and reliable privacy transaction system. Through the remote proof mechanism of trusted hardware, on-chain nodes can ensure that the off-chain verification process is authentic, reliable, and tamper-proof. Attached Figure Description

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

[0033] Figure 1 This is a flowchart of a smart contract privacy protection method in an embodiment of the present invention;

[0034] Figure 2 This is an interactive flowchart of the initialization phase in an embodiment of the present invention;

[0035] Figure 3 This is a detailed flowchart of the balance withdrawal stage in an embodiment of the present invention;

[0036] Figure 4 This is a detailed flowchart of the transfer stage in an embodiment of the present invention;

[0037] Figure 5 This is another flowchart of the smart contract privacy protection method in this embodiment of the invention;

[0038] Figure 6This is a schematic diagram of the structure of the smart contract privacy protection device in an embodiment of the present invention;

[0039] Figure 7 This is another structural schematic diagram of the smart contract privacy protection device in an embodiment of the present invention;

[0040] Figure 8 This is a schematic diagram of the structure of the smart contract privacy protection system in an embodiment of the present invention;

[0041] Figure 9 This is a schematic diagram of a computer device in an embodiment of the present invention. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0043] To address the problems existing in current technologies, this invention proposes a hybrid privacy protection scheme based on "trusted hardware and homomorphic encryption." This scheme ensures that the core logic of transactions always runs in a protected off-chain state by processing sensitive data such as user identity and balance in trusted hardware on the client side. Only the pseudonymous addresses of the sender and receiver are exposed on-chain, achieving strong anonymity for transaction participants. During the transaction, the client's identity information as the sender is completely hidden on-chain, and each transaction is unique and unlinkable, preventing any external observer from inferring user behavior from on-chain data. Furthermore, this protocol adopts a decoupled on-chain and off-chain system architecture, possessing good modularity and versatility. It can flexibly adapt to various privacy contract platforms, trusted hardware implementations, and encryption mechanisms, meeting the comprehensive requirements of privacy, security, and system performance in diverse application scenarios.

[0044] This solution relies on trusted hardware to ensure the legality and correctness of transactions. It processes only changes to the encrypted state on-chain, while completing transaction verification and sensitive data processing off-chain, thus constructing a privacy-focused transaction system architecture that combines high security and high scalability. While retaining the publicly verifiable nature of existing blockchain systems, this architecture effectively protects the identities of transaction participants, transaction details, and contract states, providing a practical technical path and system design reference for the future deployment of privacy-focused smart contracts.

[0045] First, the concepts involved in the embodiments of the present invention will be introduced.

[0046] State Consistency Design Principles: To ensure consistency between on-chain and off-chain states, this scheme adopts an "on-chain-based" balance model: the on-chain balance ciphertext is considered the only trusted source of account state, while the available balance in the off-chain TEE environment is maintained only as a controlled copy. The Trusted Hardware Equipment (TEE) in the client acts as a trusted proxy, generating a secure and isolated environment. It only updates the local available balance and generates third-party proof information after consensus or verification of the on-chain state. In the withdrawal process, the on-chain balance is first destroyed, generating a verifiable destruction proof, which is then verified and updated by the client's TEE. In the transfer process, the smart contract first verifies the transfer transaction request, updating the on-chain balance ciphertext of the sender and receiver under ciphertext conditions. This mechanism ensures strict synchronization between on-chain and off-chain states, preventing security risks or inconsistency attacks caused by state differences.

[0047] Secure isolation environment: A secure isolation environment created by the CPU within trusted hardware. The trusted hardware ensures that the code and data within this secure isolation environment are protected from interference or tampering by the host operating system or other software. It implements strict access control and encryption measures to maintain the integrity and confidentiality of the contents of the secure isolation environment.

[0048] Homomorphic encryption (HE) is an encryption technique that allows specific mathematical operations to be performed directly on ciphertext. The decrypted result is identical to the result obtained by performing the same operation on the plaintext. This encryption mechanism allows for the processing and verification of encrypted data without exposing the original data, and is widely used in security-sensitive scenarios such as privacy-preserving computing and encrypted data analysis.

[0049] Merkle: A Merkle tree is a binary hash tree structure. Leaf nodes store the hash value of a data block, while non-leaf nodes store the combination of the hash values ​​of their two child nodes. The root hash value of a Merkle tree is a unique identifier for the entire tree and can represent the integrity of all underlying data.

[0050] Figure 1 This is a flowchart of a smart contract privacy protection method in an embodiment of the present invention. The smart contract privacy protection method is applied to a client and includes:

[0051] Step 101: At startup, a secure isolation environment is created through trusted hardware, a remote proof process is initiated to the remote certification center, and the blockchain node is registered based on the first proof information received to obtain registration information;

[0052] Step 102: Initiate a balance withdrawal transaction request to the smart contract deployed on the blockchain node, so that after the smart contract destroys the on-chain balance of the client's blockchain account address, it returns the second proof information to the client's secure isolation environment;

[0053] Step 103: After verifying the second proof information in a secure isolated environment, update the local available balance according to the second proof information, encrypt the updated local available balance to obtain the local available balance ciphertext, and generate the third proof information, which is used to prove the correctness of the local available balance update.

[0054] Step 104: Receive the user's transfer transaction request, which includes the local available balance ciphertext and third-party proof information;

[0055] Step 105: Submit the transfer transaction request to the smart contract so that after the smart contract verifies the transfer transaction request based on the registration information, it updates the on-chain balance ciphertext of the sender and the receiver under ciphertext conditions, wherein the sender is the client.

[0056] In this embodiment of the invention, the client runs a conventional blockchain wallet application and integrates a secure isolation environment for processing sensitive data and transaction logic in a trusted environment.

[0057] Blockchain node: Deploys homomorphic encrypted smart contracts, is responsible for managing the on-chain encrypted balance, and cooperates in performing proof verification to ensure the correctness and integrity of the transaction process.

[0058] Remote Validation Center: It maintains remote validation services, allowing challengers to verify the identity and integrity of a secure, isolated environment.

[0059] In the protocol, a blockchain account address is maintained for each client (i.e., user) on-chain, serving as the receiving address. The on-chain balance represents the receiving balance at that address, and the on-chain balance is encrypted. To improve transfer efficiency and enhance state verifiability, the client's TEE internally maintains a global metadata field, `available_balance`, to record the client's current available balance for spending. This field is conditionally updated during the initialization, withdrawal, and transfer phases to ensure consistency with the off-chain Merkle tree state.

[0060] In step 101, at startup, a secure isolation environment is created through trusted hardware, a remote certification process is initiated to the remote certification center, and registration is performed with the blockchain node based on the first certification information received to obtain registration information;

[0061] When the client starts, it first creates a trusted, secure, and isolated environment by calling the application API through the Trusted Hardware E-Software SDK to ensure secure computation execution.

[0062] In one embodiment, after creating a secure isolation environment via trusted hardware, the method further includes:

[0063] Within a secure, isolated environment, a base key is generated, and a homomorphic key is generated in the secure, isolated environment based on the base key. The base key includes a base public key and a base private key, and the homomorphic key includes a homomorphic public key and a homomorphic private key.

[0064] Initialize the metadata field of the client's available balance to 0;

[0065] An empty Merkle tree is created in a secure, isolated environment, and a root hash is recorded. This Merkle tree is used to record information for each balance withdrawal transaction.

[0066] In this embodiment of the invention, within a secure isolation environment, the application API generates a base key by calling a secure encryption library. This base key includes a public-private key pair, referred to as the base public key pk. TEE and the underlying private key sk TEE Used to generate homomorphic keys (pk) for homomorphic operations. HE , sk HE This is called a homomorphic key, including the homomorphic public key pk. HE and homomorphic private key sk HE The basic private key sk TEE and homomorphic private key sk HE It is always kept within a secure, isolated environment and used only for local operations.

[0067] Figure 2 This is a flowchart of the interaction during the initialization phase in an embodiment of the present invention. See [link / reference] Figure 2 The verification code module is loaded in a secure, isolated environment to initialize the code. This module is used to verify the integrity and baseline consistency of the code, ensuring that the loaded code has not been tampered with.

[0068] Initialize the available_balance metadata field of the client's available balance to 0. Create an empty Merkle tree MT in a secure isolation environment, with the root hash being... The Merkle tree (MT) is used to record information for each balance withdrawal transaction. Whenever a client successfully initiates a balance withdrawal transaction, a new leaf node is added to the Merkle tree. The node content includes the transaction ID (txid) and the withdrawal amount, which is a plaintext value. Additionally, the leaf node contains a usage flag to indicate whether the leaf node is in use (unused, pending, or spent). By maintaining this Merkle tree, balance withdrawal transactions can be traced and audited when necessary, thereby improving the verifiability and auditability of account management.

[0069] In one embodiment, registration is performed with a blockchain node based on the received first proof information to form registration information, including:

[0070] A registration request is sent to a blockchain node. The registration request includes first proof information and a basic public key, so that the blockchain node can achieve consensus after receiving the first proof information and the basic public key. The basic public key is then registered to the blockchain and used as the identity identifier of the client's blockchain address account, and the client is added to the blockchain.

[0071] By initiating a remote proof process to a remote certification center through a secure and isolated environment, the system proves its trusted status to the blockchain node. The first proof information includes MRENCLAVE (a hash value reflecting the code baseline) and version information of the secure and isolated environment to ensure that the trusted baseline is consistent with expectations. After receiving the first proof information, the system sends a registration request to the blockchain node. The registration request includes the first proof information and the basic public key. After receiving the first proof information and the homomorphic public key, the blockchain node achieves consensus.

[0072] The blockchain node will PK the client's basic public key. TEE Registering with the blockchain, such as by registering in a contract or on-chain trusted list, serves as the identity identifier for the blockchain address account. For all subsequent transfer requests from this client, blockchain nodes can verify whether the third-party proof information in the transfer request has been PK'd using the registered underlying public key. TEE The process generates and confirms that the transfer transaction request indeed originated from a certified, secure, and isolated environment. The blockchain node stores a summary of the verified third-party proof on the blockchain for other clients to query and verify.

[0073] Steps 102 and 103 are the execution steps for the balance withdrawal stage. Figure 3 The following is a detailed flowchart of the balance withdrawal stage in an embodiment of the present invention, which will be described in detail below.

[0074] In step 102, a balance withdrawal transaction request is initiated to the smart contract deployed on the blockchain node, so that after the smart contract performs on-chain balance destruction on the blockchain account address of the client, it returns second proof information to the client's secure isolation environment. The second proof information is used to prove that the destruction is completed.

[0075] In one embodiment, the step of a smart contract on the blockchain performing on-chain balance destruction on the client's blockchain account address includes:

[0076] The smart contract extracts the on-chain balance ciphertext based on the client's blockchain account address in the balance withdrawal transaction request, and executes on-chain balance destruction, which involves clearing the on-chain balance ciphertext to zero to obtain a new on-chain balance ciphertext.

[0077] After the blockchain nodes jointly authenticate the legality of the on-chain balance destruction according to the preset consensus algorithm, a destruction certificate is generated based on the withdrawal amount in the on-chain balance destruction, the on-chain balance ciphertext, and the new on-chain balance ciphertext.

[0078] The smart contract updates the on-chain balance ciphertext of the blockchain account address to a new on-chain balance ciphertext and stores the destruction record on the blockchain. The destruction record includes the blockchain account address, balance ciphertext, new on-chain balance ciphertext, and destruction proof.

[0079] In this embodiment of the invention, the on-chain balance ciphertext Ce is updated to the new on-chain balance ciphertext Ce′ after being cleared to zero using the homomorphic encryption algorithm (HE) (e.g., Ce′ = HE.Sub(Ce, Ce) or HE.Enc(0)).

[0080] Blockchain nodes verify the legality of on-chain balance destruction according to consensus algorithms (PoS / oW / BFT, etc.), including: determining whether the balance withdrawal transaction request comes from an authorized client (through a public key PK). TEE (Verification); whether the balance update status complies with the contract rules; whether the operation satisfies ledger consistency. Then, it is necessary to wait for the destruction transaction to be written into the block and confirmed by enough subsequent blocks to ensure there is no risk of rollback.

[0081] A blockchain node generates a destruction proof Πd containing (Ce′, Ce), Πd = generateDestructionProof(Ce, Ce′, t2), which must satisfy: the plaintext on-chain balance corresponding to Ce′ is 0 (balance cleared); the balance difference before and after destruction is t1 = HEDec(Ce ⊕ Ce′, sk HE The amount to be withdrawn off-chain is t2, where ⊕ is a homomorphic symbol.

[0082] The smart contract deployed on the blockchain node updates the Ce of the client's blockchain account address to Ce′, and triggers a DestructionEvent for querying.

[0083] The smart contract deployed on the blockchain node transmits the initial proof information to the client's secure, isolated environment via a TLS secure channel.

[0084] In this embodiment of the invention, to prevent rollback attacks, the smart contract must wait for the on-chain balance destruction to be written into a block and confirmed by a sufficient number of subsequent blocks before it is considered to have officially taken effect. Only when a majority of blockchain nodes reach a consensus and the on-chain balance destruction is finally included in the main on-chain branch is Ce′ considered to be in a valid on-chain state, thereby ensuring that the destruction result is immutable and verifiable across the entire network, and avoiding state resets or attack windows caused by chain rollbacks.

[0085] In step 103, after verifying the second proof information in a secure isolation environment, the local available balance is updated according to the second proof information. The updated local available balance is encrypted to obtain the local available balance ciphertext, and a third proof information is generated. The third proof information is used to prove the correctness of the local available balance update.

[0086] In one embodiment, the second proof information includes the balance ciphertext, the new on-chain balance ciphertext, the destruction proof, and the on-chain balance destruction identifier;

[0087] Verifying the second proof information in a secure, isolated environment includes:

[0088] In a secure, isolated environment, use a homomorphic private key to decrypt the ciphertext of the new chain's balance and verify whether the plaintext value corresponding to the ciphertext of the new chain's balance is 0.

[0089] If so, determine whether the difference between the on-chain balance ciphertext and the new on-chain balance ciphertext is consistent with the withdrawal amount;

[0090] If so, the second proof information is confirmed to be valid.

[0091] In one embodiment, updating the local available balance based on the second proof information includes:

[0092] Construct a leaf node whose content includes an on-chain balance destruction flag, withdrawal amount, and usage flag, and set the usage flag to unused;

[0093] Insert the leaf node into the Merkle tree;

[0094] Calculate the root hash of the updated Merkle tree;

[0095] Update the local available balance based on the withdrawal amount.

[0096] In this embodiment of the invention, the newly constructed leaf node contains (txid_w, t2, flag), where flag indicates "unused". The leaf node is inserted into the Merkle tree, and the updated root hash MerkleRoot′ is recalculated. Finally, available_balance is updated by increasing the withdrawal amount t2. The local available balance (available_balance) is a resultant value, accumulated from all valid t2 values; the Merkle tree serves as a procedural record, documenting each balance withdrawal transaction that contributes to the local balance. The two have a result-based tracing relationship: local balance += t2.

[0097] In this embodiment of the invention, a secure, isolated environment can use a Merkle tree structure based on SHA256 to record locally confirmed withdrawal amounts. Each leaf node records one withdrawal record, and the hash value of each node = Hash(txid_w|| amount || flag), where || represents field concatenation. The hash value is calculated using SHA256 and serves as the unique identifier leaf_data for the leaf node. The new leaf node is appended to the set of leaf nodes in the Merkle tree, forming a new leaf node sequence: Leaves = Leaves || leaf_data. The hashing proceeds layer by layer from the bottom up from the updated set of leaf nodes until a new root hash MerkleRoot′ is obtained.

[0098] Steps 104 and 105 are the execution steps in the transfer phase. Figure 4 The following is a detailed flowchart of the transfer stage in an embodiment of the present invention, which will be described in detail below.

[0099] In step 104, a user's transfer transaction request is received, the transfer transaction request including the local available balance ciphertext and third-party proof information;

[0100] In one embodiment, the transfer transaction request further includes the sender's homomorphic public key, the receiver's homomorphic public key, the receiver's pseudonymous address, and a random number;

[0101] In step 105, the transfer transaction request is submitted to the smart contract, so that after the smart contract verifies the transfer transaction request based on the registration information, it updates the on-chain balance ciphertext of the sender and the receiver under ciphertext conditions, wherein the sender is the client.

[0102] In one embodiment, after the smart contract verifies the transfer transaction request based on registration information, the step of updating the on-chain balance ciphertext of the sender and receiver under ciphertext conditions includes:

[0103] Based on the registration information, determine whether the third proof information was issued by the registered secure isolation environment;

[0104] If so, it is determined that the third proof information is generated by the basic private key corresponding to the registered basic public key, confirming that the transfer transaction request originates from a trusted and secure isolated environment;

[0105] Check whether the random number has already been used by the client;

[0106] If not, record the random number into the client's used random number set to confirm that the verification is successful;

[0107] Based on the available balance ciphertext, the sender's homomorphic public key, the receiver's homomorphic public key, the sender's pseudonym address, and the receiver's pseudonym address in the transfer transaction request, update the on-chain balance ciphertext of the sender and receiver under the ciphertext conditions.

[0108] In this embodiment of the invention, based on the remote authentication process of the secure isolation environment between the blockchain node and the client during the initialization phase, when the blockchain receives a transfer transaction request, the smart contract needs to verify whether the transaction's third-party proof information was issued by a secure isolation environment that has completed remote authentication and is registered on the blockchain. The smart contract verifies whether the third-party proof information is issued by the registered basic public key pk. TEE The private key sk corresponding to the aforementioned blockchain address account's identity identifier TEE This is generated to confirm that the transfer transaction request indeed originated from an instance of a trusted, secure, and isolated environment.

[0109] Upon receiving a transfer request, the smart contract first checks whether the random number included in the request has already been used by the sender address (the client). If the random number is found to already exist in the historical records stored within the contract, the request is considered a duplicate transaction and is rejected. Otherwise, the random number is recorded in the sender's used random number set, and the transaction operation continues, thereby preventing replay attacks.

[0110] If the verification passes, the smart contract updates the on-chain balance ciphertext of both the sender and receiver under ciphertext conditions. The formula for updating the receiver's on-chain balance ciphertext is as follows:

[0111] , where ⊕ represents a homomorphic encryption operation.

[0112] Subsequently, the smart contract stores publicly verifiable information such as the available balance ciphertext (ΔC), the third proof information, the homomorphic public key, and the random number in the transfer transaction on the blockchain for subsequent querying and verification.

[0113] In this embodiment of the invention, the smart contract deployed on the blockchain node can verify the following key elements: whether the transfer transaction request was issued by a trusted, secure, and isolated environment that has completed remote authentication and is registered on the chain (by verifying whether the third proof information is provided by the registered public key pk). TEE The measures include: whether the random number generated in the transaction is unique (to prevent replay attacks), whether the ciphertext is in a valid homomorphic encryption format, and whether the balance update operation conforms to the logical rules set by the contract.

[0114] All of the above information is stored in the blockchain, and any on-chain node, recipient, or third-party observer can query it through the contract interface to obtain relevant fields such as transaction records, third-party proof information, homomorphic public keys, random numbers, and encrypted balances.

[0115] When the querying party can successfully verify the legality of the third-party proof information, confirm that the random number has not been reused, and determine that the ciphertext operation is consistent with the contract rules (such as the amount not exceeding the limit, address matching, etc.), the transaction can be regarded as having passed the on-chain executable verification, ensuring its integrity and validity.

[0116] Through the above-mentioned phased initialization, balance withdrawal and transfer process, the consistency and integrity of user asset data on and off the blockchain are effectively guaranteed.

[0117] To anonymize the identities of transaction participants, this embodiment of the invention utilizes a public key based on remote authentication as the pseudonymous address for both the sender and receiver, and the sender's address is not exposed during the transfer process, ensuring that the sender's identity information remains completely on-chain. Each transaction is unique and unlinkable, preventing external observers from inferring user behavior patterns through on-chain data.

[0118] This invention introduces a remote authentication mechanism using trusted hardware, establishing a trust anchor between on-chain nodes and off-chain clients. This mechanism ensures that on-chain nodes only accept requests from trusted hardware (secure and isolated environment), while off-chain clients can trust the processing performed by on-chain nodes based on authentication results, thereby building a secure and trusted foundation for interaction between the two parties.

[0119] The embodiments of the present invention protect user privacy on the client side while taking into account system performance, and are suitable for blockchain application scenarios with high requirements for transaction anonymity and security.

[0120] In this embodiment of the invention, the Paillier homomorphic encryption algorithm is used as the encryption method for the plaintext of the available balance on the chain, so as to support the addition homomorphic operation and ciphertext difference calculation on the encrypted balance.

[0121] In this embodiment, the homomorphic encryption algorithm used is the Paillier encryption scheme. Paillier is a public-key encryption algorithm based on additive homomorphism, which has good additivity, semantic security and computational efficiency, and is suitable for encryption of sensitive values ​​such as account balances and on-chain operations.

[0122] Paillier encryption is based on large integer modulo arithmetic, and its public / private key structure is as follows:

[0123] The public key is (n, g), where n = p · q is the product of two large prime numbers. Meet specific conditions;

[0124] The private key is (λ, μ), where λ = lcm(p−1, q−1). mod n, where L(x) = .

[0125] Encryption: For plaintext Random selection The ciphertext is calculated as follows:

[0126] Enc(m) = g m · r n mod n²

[0127] Decryption: For ciphertext c, the plaintext can be recovered using the following formula:

[0128] m = L(c λ (mod n²) · μ mod n

[0129] The Paillier encryption scheme satisfies the following additive homomorphic property:

[0130] Any two ciphertexts and The product of these corresponds to plaintext addition:

[0131]

[0132] Ciphertext exponentiation corresponds to scalar multiplication of plaintext:

[0133]

[0134] In this embodiment, the Paillier homomorphic encryption scheme is primarily used for addition operations on ciphertext balances (such as increasing the transfer amount) and difference calculations (such as calculating the difference ΔC when the balance is destroyed). Since this scheme only supports additive homomorphic operations, and each transaction involves only one or a few addition operations, it does not involve a large number of continuous encryption calculations. Therefore, there is no noise accumulation problem, and there is no need to introduce a complex "bootstrapping" mechanism to re-encrypt or refresh the ciphertext. Unlike schemes that support fully homomorphic encryption (FHE), Paillier, as a partially homomorphic encryption algorithm, can provide the required functionality with lower computational overhead in this embodiment, satisfying the balance between efficient on-chain execution and security requirements.

[0135] In this embodiment of the invention, the remote authentication process can select the remote proof mechanism of Intel SGX technology. The mechanism can flexibly select proof methods that enhance privacy or improve efficiency according to the application scenario, including two mainstream methods: EPID (Enhanced Privacy ID) and DCAP (Data Center Attestation Primitives), to achieve remote authentication in a trusted computing environment.

[0136] EPID is a remote proof method based on group signatures. Its main characteristics are: each processor uses the same set of public keys for signing, providing strong anonymity and preventing the disclosure of specific platform identity information. This mechanism is suitable for scenarios with high privacy protection requirements, such as digital wallets, decentralized identity authentication systems, and medical data analysis platforms, effectively preventing device identity from being tracked or associated.

[0137] DCAP is designed for high-performance scenarios such as data centers and cloud platforms, providing a more efficient proof mechanism. In DCAP, the necessary verification materials, including the Provisioning Certification Key (PCK), Trusted Computing Base (TCB), and CRL, are first obtained from Intel and cached locally. A secure, isolated environment generates a Quote when remote proof is required, and then a locally deployed verification library parses and verifies the Quote and its associated certificate chain. Because the verification process is entirely local, without real-time access to Intel's remote proof service, it offers lower authentication latency and higher processing concurrency. After successful verification, the platform's trustworthiness can be determined based on local policies, and corresponding access control or key management decisions can be executed.

[0138] EPID emphasizes anonymity and privacy protection, making it suitable for single-user, decentralized scenarios; while DCAP prioritizes performance and scalability, making it more suitable for multi-user, high-density deployment environments. The choice between these two mechanisms can be dynamically made based on actual application needs, thus ensuring both security and privacy protection while maintaining operational efficiency.

[0139] In this embodiment, the client and the blockchain node establish an encrypted communication channel through the Transport Layer Security (TLS) protocol to protect the confidentiality and integrity of data transmission in an untrusted network environment.

[0140] The client and the blockchain node establish an encrypted communication channel through the Transport Layer Security (TLS) protocol to protect the confidentiality and integrity of data transmission in untrusted network environments.

[0141] In one embodiment, the method further includes:

[0142] When initiating a connection request to a blockchain node, a set of encryption parameters are negotiated with the blockchain node through the TLS handshake protocol. These encryption parameters include a cipher suite, a random number, a digital certificate, and a public key exchange algorithm.

[0143] A shared pre-master key is negotiated with the blockchain nodes through a public key exchange algorithm, and a session key is generated based on the public key exchange algorithm and a random number.

[0144] The application layer data is symmetrically encrypted using a negotiated encryption algorithm and session key via the TLS protocol, and an integrity check code is attached.

[0145] In this embodiment of the invention, a pseudo-random function (PRF) can be used to generate a session key. This session key is only valid within the current connection and is used to encrypt and protect the integrity of subsequent application layer data. The integrity check code is a MAC or AEAD tag. Symmetric encryption of application layer data (such as HTTP requests) can prevent man-in-the-middle attacks and data tampering. Afterward, the client and the blockchain node can conduct bidirectional confidential communication through this TLS secure channel to ensure that the data is not tampered with by third parties.

[0146] This invention also proposes another method for protecting the privacy of smart contracts, which is applied to smart contracts deployed on blockchain nodes. Its principle is similar to that of the smart contract privacy protection method, and will not be described in detail here.

[0147] Figure 5Another flowchart of the smart contract privacy protection method in this embodiment of the invention includes:

[0148] Step 501: Receive a balance withdrawal transaction request initiated by the client. The client creates a secure isolation environment through trusted hardware upon startup, initiates a remote verification process with the remote authentication center, and registers with the blockchain node based on the received first verification information to obtain registration information.

[0149] Step 502: Destroy the on-chain balance of the client's blockchain account address, return second proof information to the client's secure isolation environment, so that after the client verifies the second proof information in the secure isolation environment, it updates its local available balance according to the second proof information, encrypts the updated local available balance to obtain the local available balance ciphertext, and generates third proof information; the second proof information is used to prove that the destruction is complete, and the third proof information is used to prove the correctness of the local available balance update;

[0150] Step 503: Receive a transfer transaction request submitted by the client, the transfer transaction request including the local available balance ciphertext and third-party proof information;

[0151] Step 504: Verify the transfer transaction request based on the registration information. After successful verification, update the on-chain balance ciphertext of the sender and receiver under ciphertext conditions. The sender is the client.

[0152] In one embodiment, performing on-chain balance destruction on the client's blockchain account address includes:

[0153] Based on the client's blockchain account address in the balance withdrawal transaction request, extract the on-chain balance ciphertext, and execute the on-chain balance destruction, which means clearing the on-chain balance ciphertext to zero to obtain a new on-chain balance ciphertext;

[0154] After the blockchain nodes jointly authenticate the legality of the on-chain balance destruction according to the preset consensus algorithm, a destruction certificate is generated based on the withdrawal amount in the on-chain balance destruction, the on-chain balance ciphertext, and the new on-chain balance ciphertext.

[0155] The on-chain balance ciphertext of the blockchain account address is updated to a new on-chain balance ciphertext, and the destruction record is stored on the blockchain. The destruction record includes the blockchain account address, balance ciphertext, new on-chain balance ciphertext, and destruction proof.

[0156] In one embodiment, the transfer transaction request further includes the sender's homomorphic public key, the receiver's homomorphic public key, the sender's pseudonym address, the receiver's pseudonym address, and a random number;

[0157] After the transfer transaction request is verified based on the registration information, the on-chain balance ciphertext of the sender and receiver is updated under ciphertext conditions. The sender is the client, including:

[0158] Based on the registration information, determine whether the third proof information was issued by the registered secure isolation environment;

[0159] If so, it is determined that the third proof information is generated by the basic private key corresponding to the registered basic public key, confirming that the transfer transaction request originates from a trusted and secure isolated environment;

[0160] Check whether the random number has already been used by the client;

[0161] If not, record the random number into the client's used random number set to confirm that the verification is successful;

[0162] Based on the available balance ciphertext, the sender's homomorphic public key, the receiver's homomorphic public key, the sender's pseudonym address, and the receiver's pseudonym address in the transfer transaction request, update the on-chain balance ciphertext of the sender and receiver under the ciphertext conditions.

[0163] This invention also proposes a smart contract privacy protection device, the principle of which is similar to that of the smart contract privacy protection method, and will not be described in detail here.

[0164] Figure 6 This is a schematic diagram of the structure of a smart contract privacy protection device in an embodiment of the present invention, applied to a client, including:

[0165] The initialization module 601 is used to create a secure isolation environment through trusted hardware at startup, initiate a remote proof process to the remote certification center, and register with the blockchain node based on the first proof information received to obtain registration information.

[0166] The balance withdrawal module 602 is used to initiate a balance withdrawal transaction request to the smart contract deployed on the blockchain node, so that after the smart contract destroys the on-chain balance of the client's blockchain account address, it returns second proof information to the client's secure isolation environment. The second proof information is used to prove that the destruction is completed. After verifying the second proof information in the secure isolation environment, the local available balance is updated according to the second proof information. The updated local available balance is encrypted to obtain the local available balance ciphertext, and a third proof information is generated. The third proof information is used to prove the correctness of the local available balance update.

[0167] The transfer module 603 is used to receive a user's transfer transaction request, which includes the local available balance ciphertext and third-party proof information; and to submit the transfer transaction request to the smart contract, so that after the smart contract verifies the transfer transaction request based on the registration information, it updates the on-chain balance ciphertext of the sender and the receiver under the ciphertext condition, wherein the sender is the client.

[0168] In one embodiment, the initialization module is further configured to:

[0169] After creating a secure isolation environment through trusted hardware, a base key is generated within the secure isolation environment. Based on the base key, a homomorphic key is generated in the secure isolation environment. The base key includes a base public key and a base private key, and the homomorphic key includes a homomorphic public key and a homomorphic private key.

[0170] Initialize the metadata field of the client's available balance to 0;

[0171] An empty Merkle tree is created in a secure, isolated environment, and a root hash is recorded. This Merkle tree is used to record information for each balance withdrawal transaction.

[0172] In one embodiment, the initialization module is further configured to:

[0173] A registration request is sent to a blockchain node. The registration request includes first proof information and a basic public key, so that the blockchain node can achieve consensus after receiving the first proof information and the basic public key. The basic public key is then registered to the blockchain and used as the identity identifier of the client's blockchain address account, and the client is added to the blockchain.

[0174] In one embodiment, the second proof information includes the balance ciphertext, the new on-chain balance ciphertext, the destruction proof, and the on-chain balance destruction identifier;

[0175] The balance withdrawal module is used for:

[0176] In a secure, isolated environment, use a homomorphic private key to decrypt the ciphertext of the new chain's balance and verify whether the plaintext value corresponding to the ciphertext of the new chain's balance is 0.

[0177] If so, determine whether the difference between the on-chain balance ciphertext and the new on-chain balance ciphertext is consistent with the withdrawal amount;

[0178] If so, the second proof information is confirmed to be valid.

[0179] In one embodiment, the balance withdrawal module is used for:

[0180] Construct a leaf node whose content includes an on-chain balance destruction flag, withdrawal amount, and usage flag, and set the usage flag to unused;

[0181] Insert the leaf node into the Merkle tree;

[0182] Calculate the root hash of the updated Merkle tree;

[0183] Update the local available balance based on the withdrawal amount.

[0184] This invention also proposes another smart contract privacy protection device, the principle of which is similar to the smart contract privacy protection method, and will not be described in detail here.

[0185] Figure 7 This is another structural diagram of a smart contract privacy protection device in an embodiment of the present invention, applied to a smart contract deployed on a blockchain node, including:

[0186] The first receiving module 701 is used to receive a balance withdrawal transaction request initiated by the client. The client creates a secure isolation environment through trusted hardware when it starts up, initiates a remote certification process to the remote certification center, and registers with the blockchain node according to the first certification information received to obtain registration information.

[0187] The balance destruction module 702 is used to perform on-chain balance destruction on the blockchain account address of the client, return second proof information to the client's secure isolation environment, so that after the client verifies the second proof information in the secure isolation environment, it updates the local available balance according to the second proof information, encrypts the updated local available balance to obtain the local available balance ciphertext, and generates third proof information; the second proof information is used to prove that the destruction is completed, and the third proof information is used to prove the correctness of the local available balance update;

[0188] The second receiving module 703 is used to receive a transfer transaction request submitted by the client, the transfer transaction request including the local available balance ciphertext and third proof information;

[0189] The balance ciphertext update module 704 is used to verify the transfer transaction request based on the registration information. After the verification is successful, the on-chain balance ciphertext of the sender and the receiver is updated under the ciphertext condition, wherein the sender is the client.

[0190] In one embodiment, the balance destruction module 702 is used for:

[0191] Based on the client's blockchain account address in the balance withdrawal transaction request, extract the on-chain balance ciphertext, and execute the on-chain balance destruction, which means clearing the on-chain balance ciphertext to zero to obtain a new on-chain balance ciphertext;

[0192] After the blockchain nodes jointly authenticate the legality of the on-chain balance destruction according to the preset consensus algorithm, a destruction certificate is generated based on the withdrawal amount in the on-chain balance destruction, the on-chain balance ciphertext, and the new on-chain balance ciphertext.

[0193] The on-chain balance ciphertext of the blockchain account address is updated to a new on-chain balance ciphertext, and the destruction record is stored on the blockchain. The destruction record includes the blockchain account address, balance ciphertext, new on-chain balance ciphertext, and destruction proof.

[0194] In one embodiment, the transfer transaction request further includes the sender's homomorphic public key, the receiver's homomorphic public key, the sender's pseudonym address, the receiver's pseudonym address, and a random number;

[0195] Balance ciphertext update module 704 is used for:

[0196] Based on the registration information, determine whether the third proof information was issued by the registered secure isolation environment;

[0197] If so, it is determined that the third proof information is generated by the basic private key corresponding to the registered basic public key, confirming that the transfer transaction request originates from a trusted and secure isolated environment;

[0198] Check whether the random number has already been used by the client;

[0199] If not, record the random number into the client's used random number set to confirm that the verification is successful;

[0200] Based on the available balance ciphertext, the sender's homomorphic public key, the receiver's homomorphic public key, the sender's pseudonym address, and the receiver's pseudonym address in the transfer transaction request, update the on-chain balance ciphertext of the sender and receiver under the ciphertext conditions.

[0201] Figure 8 This is a schematic diagram of the structure of the smart contract privacy protection system in an embodiment of the present invention, including a smart contract privacy protection device applied to the client, smart contracts deployed on the blockchain node, and a remote authentication center. Figure 8 The document demonstrates the functionality of each component in implementing the aforementioned method. Specifically, the client constructs a secure isolation environment, which generates homomorphic ciphertext, constructs a Merkle tree, initializes code, updates available balances, etc. The blockchain nodes deploy smart contracts, which can perform cryptographic management, integrate homomorphic algorithms, generate destruction proofs, etc. The blockchain nodes reach a consensus on the homomorphic encrypted state.

[0202] In summary, the smart contract privacy protection method, device, and system proposed in this invention combine the execution isolation advantages of trusted hardware with the strong privacy of homomorphic encryption in on-chain data encryption processing, achieving a fusion mechanism of off-chain trust in contract execution and on-chain balance management encryption security. Compared with traditional pure trusted hardware or pure cryptographic protocols (such as zero-knowledge proofs or secure multi-party computation) schemes, the hybrid architecture of this scheme has higher scalability, privacy, and deployment flexibility. On-chain smart contract execution is achieved through three stages: In the initialization stage, the client creates a secure isolation environment and completes remote proof; in the balance withdrawal stage, the smart contract destroys the on-chain balance of the client's blockchain account address and generates second proof information. After verification by the trusted hardware, the off-chain balance (i.e., the client's local available balance) is updated synchronously. The updated local available balance is encrypted to obtain the local available balance ciphertext and a third proof information is generated; in the transfer stage, the trusted hardware sends a transfer transaction request to the smart contract. The smart contract verifies the third proof information and updates the on-chain balance ciphertext of the sender and receiver under the ciphertext condition. The sender is the client. The entire process ensures transaction privacy and on-chain verifiability, constructing a highly secure and reliable privacy transaction system. Through a remote proof mechanism using trusted hardware, on-chain nodes can ensure the authenticity and immutability of the off-chain verification process. This solution achieves efficient, secure, and concurrently consistent management and transfer of privacy-preserving digital assets while maintaining user privacy, making it suitable for building blockchain wallets and payment systems with high security and privacy protection capabilities. The invention possesses good cross-platform compatibility and security robustness, and can be widely applied to on-chain privacy transaction protocols and decentralized finance (DeFi) scenarios that support homomorphic encryption.

[0203] This solution offloads transaction judgment and correctness verification to trusted hardware on the off-chain client, while only processing changes in the encrypted balance on-chain. This significantly reduces on-chain computational pressure, improves transaction confirmation efficiency and system throughput, and avoids exposing sensitive verification data on-chain, achieving a balance between high performance and strong privacy protection. Employing a decoupled on-chain and off-chain architecture, it boasts excellent versatility and scalability, flexibly adapting to different types of privacy-preserving smart contract systems, trusted hardware technologies, and various encryption and proof mechanisms. It supports efficient deployment and collaborative operation in diverse hardware and protocol environments, meeting the privacy protection and secure computing needs of complex scenarios.

[0204] This invention also provides a computer device. Figure 9This is a schematic diagram of a computer device in an embodiment of the present invention. The computer device 900 includes a memory 910, a processor 920, and a computer program 930 stored in the memory 910 and executable on the processor 920. When the processor 920 executes the computer program 930, it implements the above-mentioned smart contract privacy protection method.

[0205] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described smart contract privacy protection method.

[0206] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described smart contract privacy protection method.

[0207] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0208] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0209] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0210] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0211] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for protecting the privacy of smart contracts, characterized in that, Applied to the client side, including: Upon startup, a secure and isolated environment is created through trusted hardware, a remote verification process is initiated with the remote certification center, and registration is completed with the blockchain node based on the first verification information received to obtain registration information. A balance withdrawal transaction request is initiated to the smart contract deployed on the blockchain node, so that the smart contract performs on-chain balance destruction on the blockchain account address of the client and then returns second proof information to the client's secure isolation environment. The second proof information is used to prove that the destruction is completed. After verifying the second proof information in a secure isolated environment, the local available balance is updated based on the second proof information. The updated local available balance is then encrypted to obtain the local available balance ciphertext, and a third proof information is generated. The third proof information is used to prove the correctness of the local available balance update. Receive user transfer transaction requests, the transfer transaction requests including local available balance ciphertext and third-party proof information; The transfer transaction request is submitted to the smart contract, so that after the smart contract verifies the transfer transaction request based on the registration information, it updates the on-chain balance ciphertext of the sender and the receiver under ciphertext conditions. The sender is the client.

2. The method as described in claim 1, characterized in that, After creating a secure, isolated environment using trusted hardware, the following is also included: Within a secure, isolated environment, a base key is generated, and a homomorphic key is generated in the secure, isolated environment based on the base key. The base key includes a base public key and a base private key, and the homomorphic key includes a homomorphic public key and a homomorphic private key. Initialize the metadata field of the client's available balance to 0; An empty Merkle tree is created in a secure, isolated environment, and a root hash is recorded. This Merkle tree is used to record information for each balance withdrawal transaction.

3. The method as described in claim 1, characterized in that, Based on the first proof information received, registration is performed with the blockchain node to form registration information, including: A registration request is sent to a blockchain node. The registration request includes first proof information and a basic public key, so that the blockchain node can achieve consensus after receiving the first proof information and the basic public key, and register the basic public key to the blockchain as the identity identifier of the client's blockchain address account.

4. The method as described in claim 1, characterized in that, The second proof information includes the ciphertext of the balance, the ciphertext of the new on-chain balance, the destruction proof, and the on-chain balance destruction identifier; Verifying the second proof information in a secure, isolated environment includes: In a secure, isolated environment, use a homomorphic private key to decrypt the ciphertext of the new chain's balance and verify whether the plaintext value corresponding to the ciphertext of the new chain's balance is 0. If so, determine whether the difference between the on-chain balance ciphertext and the new on-chain balance ciphertext is consistent with the withdrawal amount; If so, the second proof information is confirmed to be valid.

5. The method as described in claim 4, characterized in that, Update the local available balance based on the second proof information, including: Construct a leaf node whose content includes an on-chain balance destruction flag, withdrawal amount, and usage flag, and set the usage flag to unused; Insert the leaf node into the Merkle tree; Calculate the root hash of the updated Merkle tree; Update the local available balance based on the withdrawal amount.

6. A method for protecting the privacy of smart contracts, characterized in that, Smart contracts deployed on blockchain nodes include: Upon receiving a balance withdrawal transaction request initiated by the client, the client creates a secure and isolated environment through trusted hardware upon startup, initiates a remote verification process with the remote certification center, and registers with the blockchain node based on the first verification information received to obtain registration information. The on-chain balance of the client's blockchain account address is destroyed, and a second proof information is returned to the client's secure isolation environment. After the client verifies the second proof information in the secure isolation environment, it updates its local available balance according to the second proof information, encrypts the updated local available balance to obtain the local available balance ciphertext, and generates a third proof information. The second proof information is used to prove that the destruction is complete, and the third proof information is used to prove the correctness of the local available balance update. Receive a transfer transaction request submitted by the client, the transfer transaction request including the local available balance ciphertext and third-party proof information; The transfer transaction request is verified based on the registration information. After successful verification, the on-chain balance ciphertext of the sender and receiver is updated under ciphertext conditions. The sender is the client.

7. The method as described in claim 6, characterized in that, Perform on-chain balance destruction on the blockchain account address of the client, including: Based on the client's blockchain account address in the balance withdrawal transaction request, extract the on-chain balance ciphertext, and execute the on-chain balance destruction, which means clearing the on-chain balance ciphertext to zero to obtain a new on-chain balance ciphertext; After the blockchain nodes jointly authenticate the legality of the on-chain balance destruction according to the preset consensus algorithm, a destruction certificate is generated based on the withdrawal amount in the on-chain balance destruction, the on-chain balance ciphertext, and the new on-chain balance ciphertext. The on-chain balance ciphertext of the blockchain account address is updated to a new on-chain balance ciphertext, and the destruction record is stored on the blockchain. The destruction record includes the blockchain account address, balance ciphertext, new on-chain balance ciphertext, and destruction proof.

8. The method as described in claim 6, characterized in that, The transfer transaction request also includes the sender's homomorphic public key, the receiver's homomorphic public key, the sender's pseudonym address, the receiver's pseudonym address, and a random number; After the transfer transaction request is verified based on the registration information, the on-chain balance ciphertext of the sender and receiver is updated under ciphertext conditions. The sender is the client, including: Based on the registration information, determine whether the third proof information was issued by the registered secure isolation environment; If so, it is determined that the third proof information is generated by the basic private key corresponding to the registered basic public key, confirming that the transfer transaction request originates from a trusted and secure isolated environment; Check whether the random number has already been used by the client; If not, record the random number into the client's used random number set to confirm that the verification is successful; Based on the available balance ciphertext, the sender's homomorphic public key, the receiver's homomorphic public key, the sender's pseudonym address, and the receiver's pseudonym address in the transfer transaction request, update the on-chain balance ciphertext of the sender and receiver under the ciphertext conditions.

9. A smart contract privacy protection device, characterized in that, Applied to the client side, including: The initialization module is used to create a secure and isolated environment through trusted hardware at startup, initiate a remote proof process to the remote certification center, and register with the blockchain node based on the first proof information received to obtain registration information. The balance withdrawal module is used to initiate a balance withdrawal transaction request to the smart contract deployed on the blockchain node. This causes the smart contract to destroy the on-chain balance of the client's blockchain account address and then return a second proof information to the client's secure isolation environment. This second proof information proves that the destruction is complete. After verifying the second proof information in the secure isolation environment, the module updates the local available balance based on the second proof information, encrypts the updated local available balance to obtain the local available balance ciphertext, and generates a third proof information. This third proof information proves the correctness of the local available balance update. The transfer module is used to receive user transfer transaction requests, which include local available balance ciphertext and third-party proof information; the transfer transaction request is submitted to the smart contract, so that after the smart contract verifies the transfer transaction request based on the registration information, it updates the on-chain balance ciphertext of the sender and the receiver under the ciphertext condition, where the sender is the client.

10. A smart contract privacy protection device, characterized in that, Smart contracts deployed on blockchain nodes include: The first receiving module is used to receive a balance withdrawal transaction request initiated by the client. The client creates a secure isolation environment through trusted hardware when it starts up, initiates a remote certification process to the remote certification center, and registers with the blockchain node based on the first certification information received to obtain registration information. The balance destruction module is used to destroy the on-chain balance of the client's blockchain account address, return second proof information to the client's secure isolation environment, so that after the client verifies the second proof information in the secure isolation environment, it updates the local available balance according to the second proof information, encrypts the updated local available balance to obtain the local available balance ciphertext, and generates third proof information; the second proof information is used to prove that the destruction is completed, and the third proof information is used to prove the correctness of the local available balance update; The second receiving module is used to receive a transfer transaction request submitted by the client, the transfer transaction request including the local available balance ciphertext and third proof information; The balance ciphertext update module is used to verify transfer transaction requests based on registration information. After successful verification, it updates the on-chain balance ciphertext of the sender and receiver under ciphertext conditions. The sender is the client.

11. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 8.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

13. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 8.

Images