Smart contract execution method, apparatus, device, medium, and program product

Abstract

This application provides a smart contract execution method, apparatus, device, medium, and program product, relating to the field of blockchain technology. The method includes: obtaining a privacy transaction package; obtaining a corresponding zero-knowledge proof based on the privacy transaction package; sending the privacy transaction package and the zero-knowledge proof to an on-chain verification node, wherein the privacy transaction package is constructed based on transaction data; constructing a first specification based on the zero-knowledge proof; authorizing the deployment of a smart contract that has passed privacy logic verification based on the first specification; processing the on-chain data generated by the execution of the deployed smart contract using a transaction prediction model to obtain a node importance assessment value; determining a transaction risk threshold based on the node importance assessment value; and triggering an interception command when the risk value corresponding to the transaction feature data exceeds the transaction risk threshold, wherein the transaction feature data is feature data extracted from the transaction data. This application can improve the applicability of smart contracts in various scenarios.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a smart contract execution method, apparatus, device, medium, and program product. Background Technology

[0002] Among related technologies, blockchain privacy protection technology mainly relies on concise non-interactive zero-knowledge proofs or ring signatures to achieve transaction privacy protection. However, traditional smart contracts rely on predefined conditions to trigger execution, lack an automatic execution mechanism based on prediction of dynamic transaction patterns, and the prediction model is disconnected from the contract execution layer, resulting in poor adaptability of smart contracts to dynamic and complex transaction scenarios. Summary of the Invention

[0003] This application provides a smart contract execution method and apparatus, which can solve the problem of poor adaptability of smart contracts to dynamic and complex transaction scenarios.

[0004] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a smart contract execution method, the method comprising: Obtain a privacy transaction package, obtain a corresponding zero-knowledge proof based on the privacy transaction package, and send the privacy transaction package and the zero-knowledge proof to the on-chain verification node, wherein the privacy transaction package is constructed based on transaction data; Based on the zero-knowledge proof, a first specification is constructed to obtain a smart contract to be deployed. Based on the first specification, the smart contract to be deployed is subjected to privacy logic verification. The smart contract to be deployed that passes the privacy logic verification is authorized to be deployed on the chain. The on-chain data generated by the execution of smart contracts deployed on the blockchain is processed through a transaction prediction model to obtain a node importance assessment value, and a transaction risk threshold is determined based on the node importance assessment value. If the risk value corresponding to the transaction feature data exceeds the transaction risk threshold, an interception command is triggered. The transaction feature data is feature data extracted from the transaction data.

[0005] Secondly, embodiments of this application provide a smart contract execution device, the device comprising: The acquisition module is used to acquire a privacy transaction package, acquire a corresponding zero-knowledge proof based on the privacy transaction package, and send the privacy transaction package and the zero-knowledge proof to the on-chain verification node, wherein the privacy transaction package is constructed based on transaction data; The verification module is used to construct a first specification based on the zero-knowledge proof, obtain the smart contract to be deployed, perform privacy logic verification on the smart contract to be deployed based on the first specification, and authorize the deployment of the smart contract to be deployed on the chain if the privacy logic verification is qualified. The processing module is used to process the on-chain data generated by the execution of smart contracts deployed on the chain through a transaction prediction model in order to obtain a node importance assessment value and determine a transaction risk threshold based on the node importance assessment value. The triggering module is used to trigger an interception command when the risk value corresponding to the transaction feature data exceeds the transaction risk threshold, wherein the transaction feature data is feature data extracted from the transaction data.

[0006] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory stores a program or instructions that can run on the processor, and when the program or instructions are executed by the processor, they implement the steps of the smart contract execution method as described in the first aspect.

[0007] Fourthly, embodiments of this application provide a readable storage medium storing a program or instructions that, when executed by a processor, implement the steps of the smart contract execution method as described in the first aspect.

[0008] In this embodiment, a privacy transaction package is obtained, and a corresponding zero-knowledge proof is obtained based on the privacy transaction package. The privacy transaction package and the zero-knowledge proof are then sent to an on-chain verification node. The privacy transaction package is constructed based on transaction data. A first specification is constructed based on the zero-knowledge proof, and a smart contract to be deployed is obtained. Privacy logic verification is performed on the smart contract to be deployed based on the first specification. The smart contract to be deployed that passes the privacy logic verification is authorized for on-chain deployment. The on-chain data generated by the execution of the deployed smart contract is processed through a transaction prediction model to obtain a node importance assessment value. A transaction risk threshold is determined based on the node importance assessment value. If the risk value corresponding to the transaction feature data exceeds the transaction risk threshold, an interception command is triggered. The transaction feature data is feature data extracted from the transaction data. In this way, by combining privacy transaction packages with zero-knowledge proofs, verifying contract privacy logic led by the first specification, and determining dynamic risk thresholds and triggering interception instructions driven by transaction prediction models, smart contracts can be flexibly adapted to different application scenarios. They can be matched more accurately with scenarios such as finance and government affairs that have high requirements for transaction privacy and compliance and have varied on-chain transaction scenarios. They can meet the privacy protection and risk control needs of sensitive scenarios, as well as the efficient execution needs of ordinary on-chain transaction scenarios, thereby improving the applicability of smart contracts in various scenarios. Attached Figure Description

[0009] Figure 1 A flowchart illustrating the smart contract execution method provided in this application embodiment; Figure 2A flowchart illustrating the implementation of the zk-STARKs improvement scheme provided in this application embodiment; Figure 3 This is a structural diagram of a modular engine system provided in an embodiment of this application; Figure 4 A flowchart illustrating the implementation of the formal verification algorithm for smart contracts provided in this application embodiment; Figure 5 A flowchart illustrating the implementation of the smart contract execution method provided in this application embodiment; Figure 6 This is a schematic diagram of the structure of the smart contract execution device provided in the embodiments of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0011] For ease of understanding, the following describes some aspects of the embodiments of this application: In the field of smart contract execution, the mainstream solutions currently fall into three main categories: First, regarding the current state of blockchain privacy protection technology: Related technologies primarily rely on concise, non-interactive zero-knowledge proofs (zk-SNARKs) or ring signatures to protect transaction privacy. However, these technologies suffer from issues such as dependence on trusted initialization, high computational overhead, and insufficient privacy granularity (only hiding the address or amount). Typical solutions include ring signatures for hiding addresses (Monero) and zk-SNARKs for hiding transaction amounts (Zcash).

[0012] Secondly, regarding the current state of formal verification of smart contracts: Related formal verification tools, such as the Solidity verification framework, are mostly aimed at code security, lack the ability to verify privacy protection logic, and have low verification coverage (only covering part of the contract logic).

[0013] Regarding the current state of trading pattern prediction and automated execution technologies: Traditional smart contracts rely on predefined conditions to trigger execution, such as oracle inputs. They lack an automatic execution mechanism based on predictions of dynamic transaction patterns, and the prediction model is disconnected from the contract execution layer.

[0014] However, the relevant technologies have the following drawbacks: Insufficient privacy protection, the relevant technologies cannot hide transaction amount and address at the same time, and zero-knowledge proof protocols have security vulnerabilities (such as trusted initialization dependency).

[0015] The low coverage of formal verification and the lack of automated verification of privacy protection logic lead to a high risk of contract vulnerabilities.

[0016] Prediction and execution are disconnected. Traditional Long Short-Term Memory (LSTM) network models are not integrated with the smart contract execution layer and cannot achieve dynamic triggering.

[0017] The lack of a dynamic execution mechanism means that existing contracts rely on static conditions and cannot adapt to the dynamic needs of complex transaction scenarios.

[0018] Therefore, this application proposes a privacy protection scheme that supports dual concealment of transaction amount and address. It enables formal verification of smart contract privacy logic, improving security coverage. This is achieved by constructing a dynamic execution framework based on an LSTM-based transaction prediction model and an automatic triggering mechanism. A verifiable privacy smart contract engine is designed, supporting end-to-end privacy protection and dynamic execution.

[0019] The following description, in conjunction with the accompanying drawings, further illustrates the smart contract execution method, apparatus, device, and storage medium proposed in the embodiments of this application.

[0020] Please see Figure 1 , Figure 1 A flowchart illustrating a smart contract execution method provided in this application embodiment is shown in the figure. The method includes: Step 110: Obtain a privacy transaction package, obtain a corresponding zero-knowledge proof based on the privacy transaction package, and send the privacy transaction package and the zero-knowledge proof to the on-chain verification node, wherein the privacy transaction package is constructed based on transaction data; In this step, transaction data can be understood as various core data generated or to be executed during the execution of a smart contract. This data can include basic information such as the addresses of transaction participants, transaction amount, and transaction time, as well as derived information such as transaction frequency and historical anomaly records. This type of data is the core basis for smart contract execution and a key object for privacy protection. Constructing a privacy transaction package based on the above transaction data refers to encrypting or obfuscating the sensitive information that needs protection within the transaction data and then encapsulating it into a standardized data packet. This process can employ a layered zero-knowledge proof architecture to hide sensitive information such as transaction amount and transaction address, or it can use a combination of multinomial commitments and hash obfuscation to encapsulate the core data, thereby preventing sensitive information from being directly exposed on the blockchain.

[0021] The aforementioned zero-knowledge proof is a method of proving that private information conforms to preset rules without disclosing the private information itself. Based on a privacy transaction package, the corresponding zero-knowledge proof can be obtained. It can generate an integrity proof including hidden amounts and obfuscated addresses using the zk-STARKs algorithm, or a lightweight zero-knowledge proof using the Groth16 protocol to meet the needs of rapid on-chain verification. On-chain verification nodes are the nodes in the blockchain network responsible for verifying the legality of transactions. After the privacy transaction package and the zero-knowledge proof are sent to the on-chain verification node, the node can first perform a lightweight hash check on the zero-knowledge proof, or first verify the format compliance of the privacy transaction package, before proceeding with subsequent privacy logic verification work. This ensures that the submitted transaction data meets both privacy protection requirements and the basic access rules of the blockchain network.

[0022] In some alternative implementations, the transaction data can be preprocessed. For example, the user client inputs the transaction amount (amount) and the receiving address (addr), and the client generates random numbers r1 (amount obfuscation factor) and r2 (address obfuscation factor).

[0023] Step 120: Construct a first specification based on the zero-knowledge proof, obtain a smart contract to be deployed, perform privacy logic verification on the smart contract to be deployed based on the first specification, and authorize the deployment of smart contracts that pass the privacy logic verification to be deployed on the chain. In this step, the first specification is a standardized rule system used to determine whether the privacy logic of a smart contract is compliant. Constructed based on zero-knowledge proofs, the first specification can formulate compliance rules for hiding amounts around the privacy protection dimensions corresponding to zero-knowledge proofs, or corresponding judgment rules around the non-associative nature of addresses. This provides a unified basis for privacy logic verification, ensuring that the verification standard is consistent with the protection logic of the privacy transaction package. Smart contracts to be deployed refer to smart contracts that have not yet been run on the blockchain and are in the pre-deployment review stage. These contracts can be obtained through the contract submission interface of the blockchain development platform or through the contract application channel within the consortium blockchain, ensuring that the contracts to be verified cover different business scenarios such as financial transactions and asset transfers. The aforementioned privacy logic verification refers to testing the code logic of the smart contract according to the first specification to confirm whether it meets the preset privacy protection requirements. This verification process can use formal verification tools to convert the smart contract code into a verifiable intermediate representation for static verification, or it can combine off-chain simulation execution for dynamic verification. Through multi-dimensional verification, it ensures that the smart contract will not have privacy logic vulnerabilities after deployment. For smart contracts that pass verification, the system allows them to access the blockchain network and complete on-chain deployment. Contracts that fail verification must be logically corrected based on the verification results and then resubmitted for verification.

[0024] Step 130: Process the on-chain data generated by the execution of the smart contract deployed on the chain through the transaction prediction model to obtain the node importance assessment value, and determine the transaction risk threshold based on the node importance assessment value; In this step, the aforementioned on-chain data refers to the full amount of data generated during the operation of smart contracts after deployment on the blockchain. This data can include the execution records of each transaction, contract state change information, etc. When processing this type of data, the transaction prediction model can first group the data according to time series, spatial, and behavioral characteristics, or it can first clean the data of outliers before performing feature extraction, thereby improving the accuracy of data processing. The node importance assessment value is a quantitative assessment result of the risk level of transaction nodes in the blockchain network. This assessment value can be obtained by weighting indicators such as the proportion of transaction amount and the frequency of anomalies through a multi-dimensional assessment system, or by comprehensively judging the location characteristics of transaction nodes in the network topology. This assessment value can intuitively reflect the risk level of transaction nodes. The transaction risk threshold is the critical value that triggers the risk control interception command. This threshold is determined based on the node importance assessment value. It can be dynamically calculated by combining the reconstruction error standard deviation of on-chain data, or a differentiated benchmark threshold can be set according to the risk control needs of different business scenarios, and then adjusted in combination with the node importance assessment value to ensure that the threshold can not only adapt to the risk characteristics of different nodes, but also meet the requirements of financial-grade real-time risk control.

[0025] Step 140: If the risk value corresponding to the transaction feature data exceeds the transaction risk threshold, an interception command is triggered. The transaction feature data is feature data extracted from the transaction data.

[0026] In this step, the aforementioned transaction characteristic data refers to the core data extracted from the original transaction data that reflects the characteristics of transaction risk. This data can include basic characteristics such as the fluctuation range of transaction amount and the degree of anomaly of the counterparty, as well as derived characteristics such as the topological centrality and temporal correlation of transaction nodes. This type of data is the core basis for determining transaction risk. When the transaction characteristic data exceeds the transaction risk threshold, the system will trigger an interception instruction. The interception instruction is a risk control execution instruction triggered for high-risk transactions. It can be a high-risk interception instruction that freezes the account and repatriates funds, a medium-risk interception instruction that delays the transaction and pushes it to the manual review queue, or a low-risk interception instruction that asynchronously marks, monitors, and limits the flow. Through differentiated interception instructions, precise control over transactions of different risk levels is achieved, ensuring the security and stability of the smart contract execution process. "When the risk value corresponding to the transaction feature data exceeds the transaction risk threshold" is the core judgment condition for triggering a risk interception command during smart contract execution. This can be understood as comparing a quantitative indicator extracted from the original transaction data that characterizes the transaction risk attribute with a risk threshold dynamically determined based on node importance assessment values. When the value of this quantitative indicator (or matching degree, anomaly probability, etc.) exceeds the preset threshold, the transaction is determined to have reached a preset risk level, thereby triggering the corresponding interception command. Here, "exceeding" is not limited to an absolute numerical value exceeding the threshold; it can also refer to an excess of relative indicators such as the degree of feature anomaly or probability value. The specific judgment logic can be flexibly set according to the risk control needs of different business scenarios such as finance, government affairs, and supply chain, ensuring the accuracy of risk assessment and scenario adaptability.

[0027] For example, for financial smart contracts, the transaction characteristic data extracted from the transaction data is "the fluctuation range of a single node's single transaction amount relative to the node's average transaction amount over the past 7 days." Combined with the node's importance assessment value (high-risk node), the transaction risk threshold is determined as "fluctuation exceeding 200%." ​​When a high-risk transaction node initiates a transaction of 1 million yuan, and the node's average transaction amount over the past 7 days is 300,000 yuan, the calculated fluctuation range is approximately 233%, exceeding the 200% transaction risk threshold. This satisfies the condition that "the transaction characteristic data exceeds the aforementioned transaction risk threshold," and the system will trigger the corresponding interception command.

[0028] In the smart contract execution method of this application embodiment, LSTM transaction prediction and Auto-Trigger mechanism, which integrate time series features and address association analysis, trigger dynamic contract execution through off-chain prediction-on-chain verification collaborative mechanism; For example, the overall transaction process can be as follows: 1. Transaction Initiator: The entire process begins with the transaction initiator, who generates the intention to conduct the transaction and prepares to carry out the relevant transaction operations.

[0029] 2. Generate raw transaction data: The transaction initiator generates raw transaction data according to the transaction requirements. This data may include relevant transaction information, such as the transaction amount, the addresses of both parties (in processed form), and other specific details.

[0030] 3. Constructing a Privacy-Preserving Transaction Package: The results obtained from the layered proof generation section can be combined with the original transaction data to construct a privacy-preserving transaction package that includes privacy protection measures. This transaction package can hide key privacy information of the transaction while ensuring that the transaction proceeds normally.

[0031] 4. Layered Zero-Knowledge Proof Generation: Based on a pre-constructed privacy transaction package, corresponding zero-knowledge proofs can be generated according to layered logic and the principles of zero-knowledge proofs. Zero-knowledge proofs enable the verifier to verify the legality and other key attributes of a transaction without obtaining the transaction's private information.

[0032] 5. On-chain verification nodes: These nodes can send the generated privacy transaction packages and zero-knowledge proofs to on-chain verification nodes. These nodes play a crucial role in the blockchain network, verifying whether transactions meet requirements.

[0033] 6. Determine if verification is successful: The verification node verifies the received transaction-related proofs and other information.

[0034] Yes: If the verification passes, the "Update Privacy Ledger" operation will be executed. This indicates that the transaction is approved, and the relevant ledger information (such as account balance) will be updated according to the transaction content, and the update will be based on privacy protection logic to ensure that privacy information is not leaked.

[0035] No: If the verification fails, the transaction will be discarded. This means that the transaction has a problem (such as the privacy proof not meeting the requirements, or the transaction itself being faulty), and will be discarded by the blockchain network without affecting the ledger.

[0036] In the smart contract execution method of this application embodiment, by combining privacy transaction packages with zero-knowledge proofs, verifying contract privacy logic dominated by the first specification, determining dynamic risk thresholds driven by transaction prediction models, and triggering interception instructions, the smart contract achieves flexible adaptation to different application scenarios. It can more accurately match scenarios such as finance and government affairs that have high requirements for transaction privacy and compliance and have varied on-chain transaction scenarios. It can not only meet the privacy protection and risk control needs of sensitive scenarios, but also adapt to the efficient execution needs of ordinary on-chain transaction scenarios, thereby improving the applicability of smart contracts in various scenarios.

[0037] In addition, some optional implementations may include a formal verification engine that can use Coq's omega (linear arithmetic) and ring (polynomial simplification) automation strategies to verify privacy specifications. If the verification passes, a verification report is generated. If the verification fails, the path of least negative example (such as an emit event where the amount is not hidden) is output, and the vulnerability location is marked.

[0038] Optionally, the transaction data includes the transaction amount and the real user address, and the process of obtaining the privacy transaction package includes: Generate a random number with obfuscated amount and a random number with obfuscated address based on the transaction data; A multinomial commitment is used to encode the transaction amount in the transaction data and the amount-mixed random number to generate an amount commitment value; Based on the hash algorithm, a proof public parameter is generated by combining the real user address in the transaction data, the address confusion random number and the block height corresponding to the transaction timestamp, and a temporary address is generated based on the proof public parameter. The promised amount and the temporary address are hashed together to generate an integrity proof; The privacy transaction package is constructed based on the transaction data, the temporary address, and the integrity proof.

[0039] Amount obfuscation random numbers are random values ​​used to obfuscate the transaction amount in transaction data. This can be used in conjunction with subsequent encoding operations to hide the true transaction amount and prevent direct identification of the amount information. Address obfuscation random numbers are random values ​​used to obfuscate the real user address in transaction data. This can be used to help generate untraceable temporary addresses, protecting the privacy of the transaction subject's identity. When generating these two types of random numbers, a cryptographically secure random number generator can be used to ensure the uniqueness and unpredictability of the random numbers, preventing malicious attacks. Alternatively, unique identifiers such as transaction timestamps and transaction sequence numbers can be combined to generate random numbers bound to the transaction, further enhancing the security and relevance of the random numbers. This ensures that the obfuscated random number corresponding to each transaction is unique, improving the reliability of privacy protection.

[0040] Multinomial commitment is a scheme that proves a value belongs to a specific polynomial without revealing the original data. It can encrypt and encode the transaction amount and its obfuscated random number, making the encoded result impossible to reverse-engineer, thus hiding the true transaction amount. During the encoding process, the Pedersen multinomial commitment algorithm can be used, taking the transaction amount and obfuscated random number as input parameters to the polynomial to generate the corresponding commitment value; alternatively, the KZG multinomial commitment algorithm can be used, obtaining an immutable commitment value through polynomial evaluation and commitment generation. The encoded commitment value can only be verified through the corresponding zero-knowledge proof; the original transaction amount and obfuscated random number cannot be directly obtained, effectively protecting the privacy and security of the transaction information. The generated commitment value will serve as a core component of the privacy transaction package for subsequent integrity verification and on-chain validation.

[0041] The proof public parameters are the set of basic parameters used to generate temporary addresses. They integrate three core types of information: the real user address, the address obfuscated random number, and the block height. This ensures the uniqueness of the generated temporary address and prevents it from being traced back to the real user address. The block height, the blockchain block number corresponding to the transaction timestamp, is time-sequentially unique. Combining the block height with the temporary address prevents the generation of duplicate temporary addresses from the same real address, further strengthening the address non-associativity. The hash algorithm used can be the SHA3 series, which generates the proof public parameters by hashing the three core types of information; or it can be the Keccak series, which improves the security of the parameters through multiple rounds of hash iteration to prevent malicious cracking. When generating temporary addresses based on the proof public parameters, the result of the hash operation can be used as the core identifier of the temporary address and standardized; alternatively, the parameter result can be adapted by combining it with the address encoding rules of the blockchain network to ensure that the generated temporary address meets the address format requirements of on-chain transactions and can participate in on-chain transaction interactions normally.

[0042] Hash fusion is the process of integrating the committed amount and the temporary address using a hash algorithm. Its core purpose is to ensure the consistency and integrity of the committed amount and the temporary address, preventing them from being tampered with separately and ensuring the credibility of the privacy transaction package. Hash fusion can be performed using either sequential hash fusion, where the committed amount is hashed first, and then the result is combined with the temporary address for a second hash to generate an integrity proof; or weighted hash fusion, where different weights are assigned based on the importance of the committed amount and the temporary address before hashing to generate an integrity proof demonstrating their relationship. The generated integrity proof verifies whether the committed amount and the temporary address originate from the same transaction and whether they have been tampered with. It serves as a crucial basis for subsequent on-chain verification nodes to validate the legality of the privacy transaction package, ensuring that the privacy transaction package is not maliciously tampered with during transmission and verification, thus protecting transaction privacy and security.

[0043] A privacy transaction package is a standardized data packet containing core transaction information that has undergone privacy protection processing. It must both conceal sensitive information within the transaction data and include the core elements required for on-chain verification, ensuring effective validation by on-chain verification nodes. When constructing a privacy transaction package, non-sensitive information from the transaction data, along with temporary addresses and integrity proofs, can be standardized and encapsulated, organizing the data according to a fixed format to adapt to the verification protocols of different blockchain nodes. Alternatively, the encapsulated data can be compressed according to the transmission requirements of the blockchain network, reducing data transmission overhead and improving transmission efficiency. The completed privacy transaction package contains the core information required for transaction execution while protecting sensitive information through temporary addresses, committed amounts, and integrity proofs. It can be successfully sent to on-chain verification nodes for verification, ensuring that sensitive information such as the identity of the transaction parties and the transaction amount is not leaked.

[0044] In this implementation, a layered zero-knowledge proof architecture is proposed, which can combine multinomial commitment and hash chain technology to achieve dual hiding of transaction amount and address, and optimize the efficiency of proof generation and verification. In the smart contract execution method of this application embodiment, double hiding can be achieved. The traditional zk-STARKs protocol can be reconstructed through a layered zero-knowledge proof architecture. The transaction amount can be encoded as ciphertext on an elliptic curve using a multinomial commitment (such as PedersenCommitment) through a monetary hiding layer, and the validity of the amount can be proved through STARKs (such as Σinput = Σoutput + transaction fee), thus avoiding reliance on trusted initialization. In some optional implementations, a dynamic hash chain binding mechanism can be introduced into the address obfuscation layer. This generates a temporary address `temp_addr = Hash(real address || random number || block height)` based on the transaction timestamp, and embeds the random number into the common proof parameters to prevent address association analysis. Verification optimization can be achieved by compressing the proof size using Low-Degree Extension (LDE), increasing verification speed by 60% (compared to similar solutions), while also supporting fast verification by light nodes on the chain. Its core flowchart can be seen as follows: Figure 2 As shown; For example, the layered proof generation part can be as follows: Amount Hiding Layer: This is the starting part of the layered proof generation. Its main purpose is to process all the information that needs to be hidden, ensuring that this information can be effectively hidden in subsequent transactions and other operations, thus laying the foundation for the entire privacy protection process.

[0045] Multinomial Commitment: After completing the operation of the amount hiding layer, multinomial commitment can be performed. Through mathematical multinomial commitment schemes, commitments can be made to certain data (such as polynomials related to transaction information), so that this data can be verified in the subsequent proof process without directly exposing the original data itself.

[0046] Address Obfuscation Layer: This stage involves obfuscating address information within a transaction. This prevents the easily identifiable privacy information, such as the addresses of both parties, from being readily identified. Through obfuscation, address information becomes difficult to trace and associate with specific entities during the transaction process.

[0047] Hash chain binding: The properties of hash chains can be used to bind related parts (such as previously processed transaction information). Hash chains provide a unidirectional and tamper-proof structure, ensuring data integrity and consistency, allowing subsequent verification and other operations to be performed based on this binding relationship.

[0048] After completing the above operations, an integrity certificate can be generated. This integrity certificate can be used to demonstrate to the verifier that the entire transaction process and the processing of related data are complete and have not been tampered with, ensuring the reliability and credibility of the transaction.

[0049] In some alternative implementations, layered proof generation can be achieved through the privacy engine core module: The specific steps for hiding the amount in Layer 1 are as follows: Input: Transaction amount (amount), random number r1 (amount obfuscation factor) The steps for generating a Pedersen commitment can be as follows: The hidden amount value is generated using Pedersen commitment: C_amount = g^amount *h^r1. Where g and h are the base points of the elliptic curve.

[0050] LDE polynomial constraints: Constraining the legality of the transaction amount, such as The encoding is a low-order extended polynomial (order ≤ 3) to reduce redundant calculations.

[0051] For example, the constraints are encoded as polynomials poly_constraints = [ input_sum - output_sum - fee == 0, amount >= 0 # Non-negativity constraint ] Integrity proof layer: zk-STARKs proof generation: Furthermore, compact proofs can be generated based on LDE, optimizing the proof size (reducing it by 30% compared to traditional STARKs).

[0052] Output: Hidden amount proof π_amount, commitment value C_amount Layer 2 Address Obfuscation: Input: User's real address (addr), random number (r2), current block height (block_height) Furthermore, a temporary address temp_addr = Hash(addr||r2||block_height) can be generated using hash chain binding, and r2 can be embedded in the public parameters of the proof; The specific steps for generating address obfuscation proof are as follows: Generate proof π_addr and verify the legality of the association between temp_addr and addr.

[0053] Furthermore, Layer 3 integrity proof: Input: π_amount, π_addr Technical Implementation: Hash chain binding: Generate the final proof: This ensures the immutability of the two-layer proof.

[0054] On-chain verification optimization: Lightweight verification contracts can be designed, requiring only the verification of π_final and common parameters, without the need for a complete STARKs circuit.

[0055] Output: Compressed proof π_final.

[0056] For example, the code for an on-chain lightweight zero-knowledge proof verification contract can be as follows: function verifyFinalProof(bytes calldata π_final, PublicInputscalldata inputs) public { bytes32 computed_hash = sha3(n_amount, n_addr, inputs.C_amount, inputs.temp_addr); require(computed_hash == π_final, "Invalid final proof");} In some other alternative implementations, a modular engine system can be built, which can integrate a zk-STARKs proof generator and address obfuscation module into the privacy protection layer to output standardized privacy transaction packages; deploy the Coq verification toolchain and zero-knowledge proof verification contracts (such as PrivacyVerifier.sol) in the verification layer; run a multi-task model and an Auto-Trigger executor in the execution layer to dynamically respond to on-chain events; and support multi-chain adaptation (such as Ethereum and Polkadot) through plug-in interfaces for scalability, while reserving access points for regulatory audit modules.

[0057] In some other alternative implementations, see [reference]. Figure 3 The module interaction logic can be as follows: Privacy protection layer: Signal processing: Receives the original transaction input and outputs a privacy transaction package with zero-knowledge proof.

[0058] Physical connection: Communicates with blockchain nodes via API interface (gRPC protocol).

[0059] Formal verification layer: Functional logic: Force Coq verification before contract deployment; contracts that fail verification cannot be uploaded to the blockchain.

[0060] Anomaly Handling: When a privacy breach risk is detected, automatically insert fix code (such as forced amount obfuscation).

[0061] Dynamic execution layer: Event listening: Trigger prediction model updates by subscribing to on-chain events (such as NewBlock).

[0062] Execution constraints: Auto-Trigger operations require consensus signatures from at least 3 validator nodes.

[0063] Furthermore, the technical essence of the layered zero-knowledge proof architecture can be understood as a three-level proof structure of "amount hiding layer - address obfuscation layer - integrity layer".

[0064] The amount hiding layer can use a third-order LDE polynomial to compress the Pedersen commitment and generate a proof π_amount (size ≤ 32KB). The address obfuscation layer can generate temporary addresses and prove π_addr based on quantum-resistant hash SHA3-256(addr||r2||block_height); Integrity layer: Hash chain binding π_final = SHA3-256(π_amount || π_addr || C_amount).

[0065] In the smart contract execution method of this application embodiment, a complete process for sensitive information protection and transaction package construction is formed by generating exclusive obfuscated random numbers, multinomial commitment encoding, temporary address generation, hash fusion verification, and standardized encapsulation. This process can adapt to different types of transaction data and blockchain networks. It can ensure that sensitive transaction information is not leaked through multi-stage privacy obfuscation, and it can guarantee the credibility and verifiability of the transaction package through integrity proof. This allows the constructed privacy transaction package to flexibly adapt to various on-chain verification scenarios, further improving the privacy protection system for transaction data and laying a solid foundation for subsequent zero-knowledge proof verification and on-chain transaction execution.

[0066] Optionally, the first specification includes at least one of the following: compliance with amount concealment, address non-association, and resistance to replay attacks; The on-chain verification nodes are used to verify the integrity of the privacy transaction package and perform tiered processing on the transaction based on the node importance assessment value.

[0067] In this implementation, the aforementioned first specification serves as a standardized rule system for determining the compliance of smart contract privacy logic. Specifically, it may include at least one of the following: compliance of amount hiding, address non-association, and resistance to replay attacks. Alternatively, it may cover all three rules simultaneously, based on the privacy protection needs of actual business scenarios, thereby forming a multi-dimensional privacy compliance determination system to ensure that the privacy protection logic of smart contracts covers key dimensions such as the protection of core transaction information and defense against security attacks.

[0068] The compliance requirement for concealed transaction amounts means that smart contracts must not directly expose transaction amount information on the blockchain during transaction execution. This rule can be determined based on zero-knowledge proof verification results, confirming that the transaction amount is presented only as a commitment value and cannot be reverse-derived. Alternatively, formal verification tools can be used to detect logical vulnerabilities in the contract code that directly output plaintext amounts. This ensures the privacy protection of transaction information and prevents the leakage of sensitive information such as the transaction entity's financial size due to plaintext exposure of amounts.

[0069] Address non-association requires that there be no unique correspondence between the real addresses of the participants in a transaction processed by a smart contract and the addresses presented on the blockchain. This rule can be implemented by verifying the compliance of the temporary address generation logic, confirming that temporary addresses are generated by hashing parameters such as real addresses combined with random numbers and block height, and are untraceable. It can also be achieved by detecting the correlation between temporary addresses in different transactions, ensuring that different temporary addresses corresponding to the same real address are not identified as related addresses, thereby preventing the leakage of transaction entity identities due to address association analysis.

[0070] Replay attack resistance requires smart contracts to have the ability to resist the repeated submission of the same transaction for undue gain. This rule can be implemented by embedding unique identifiers such as timestamps or block heights in the transaction package to ensure that the same transaction can only be verified within a specified time range. Alternatively, it can be achieved by recording the hash information of verified transactions on the chain, and directly rejecting verification when a duplicate transaction hash is detected, thereby eliminating security risks such as asset loss and transaction disorder caused by replay attacks.

[0071] The aforementioned on-chain verification nodes can serve as core nodes in the blockchain network responsible for transaction and contract verification. Their core responsibilities include verifying the integrity of privacy transaction packages and performing tiered processing of transactions based on the node's importance assessment value. These two responsibilities work together to ensure the credibility of transaction data throughout the entire process from submission to verification, and to achieve precise control over transactions of different risk levels.

[0072] Verifying the integrity of a privacy transaction package means confirming that it has not been tampered with during transmission and submission. This verification process can be achieved by calculating the hash value of the privacy transaction package and comparing it with a pre-submitted hash result. If they match, the privacy transaction package is considered complete. Alternatively, a zero-knowledge proof-based integrity layer verification logic can be used to confirm that core information such as the amount commitment and temporary address in the privacy transaction package matches the proof content. This ensures the validity of the privacy transaction package and prevents privacy protection failure or incorrect transaction results due to transaction package tampering.

[0073] A formal verification framework covering privacy logic can be built. The specification definition uses Coq to define formal specifications for privacy attributes (such as non-associability and compliance with hidden amount rules), and develops the specification library ZKP_Properties.v. Semantic transformation uses the compiler Sol2Coq to convert Solidity contracts into Coq intermediate representations (IR), preserving the semantics of privacy-related operations. Automated verification calls the Coq engine to perform theorem proofs, detecting risks such as unencrypted amount exposure and address associatability vulnerabilities, and automatically generating remediation suggestions (such as inserting obfuscated code).

[0074] It is possible Figure 4 As shown, a formal specification definition (covering privacy attributes) of a basic security specification may include at least one of the following: The absence of integer overflow ensures that numerical calculations during transactions (such as monetary calculations) do not exceed the range of integers that a computer can represent due to values ​​being too large or too small, thus preventing erroneous calculation results. Such errors can lead to serious security problems, such as incorrect account balances.

[0075] Prohibition of Reentrancy Attacks: Reentrancy attacks are a common method of exploiting security vulnerabilities, allowing attackers to steal funds or other resources by repeatedly calling the same function before a transaction is completed. This specification aims to prevent this from happening. While it overlaps with existing technologies (such as state checks in smart contract programming), it is briefly described here.

[0076] Privacy attribute specifications may include at least one of the following: Amount Hiding Compliance: A specification called Amount Hiding Compliance can be defined to ensure that the hiding of transaction amounts is compliant. Specifically, it states that there exists a random number *r* such that the result of making a commitment between the transaction amount and this random number using the Pedersen commitment function equals the commitment value contained in the transaction. This ensures that the transaction amount is effectively hidden during transmission and storage, and only someone with the correct random number can decrypt the true transaction amount, thus protecting the privacy of the transaction amount.

[0077] Address Unlinkability: An Address Unlinkability specification can be defined to ensure that addresses between different transactions cannot be associated. When two transactions have different temporary addresses, their corresponding real addresses are also different. Temporary addresses can be generated in privacy transactions and used to perform transaction operations in place of real addresses. The purpose of this specification is to prevent the tracking and association of the real identities of the parties involved in a transaction by analyzing transaction addresses, thereby enhancing the privacy protection of transaction participants.

[0078] Anti-replay attack: An Anti-Replay specification can be defined to prevent transactions from being replayed. It requires that for each transaction, the block height must be greater than the height of all old replay blocks (old_replay). This ensures that transactions are only valid within a specific height range, preventing attackers from repeatedly submitting old transactions in new blocks, thus protecting the security and validity of transactions.

[0079] For example, the configuration can be as follows: (* 1. Compliance of concealing amounts *) Definition AmountHidingCompliance (tx: Transaction) : Prop := exists (r: Rand), pedersen_commitment(tx.amount, r) = tx.commitment. (* 2. Address non-association*) Definition AddressUnlinkability (tx1 tx2: Transaction) : Prop := tx1.temp_addr <> tx2.temp_addr → tx1.real_addr <> tx2.real_addr. (* 3. Anti-replay attack*) Definition AntiReplay (tx: Transaction) : Prop := forall (old_block: Block), tx.block_height > old_block.height. In the smart contract execution method of this application embodiment, transaction execution is graded based on node importance assessment values. Specifically, based on the risk quantification assessment results of transaction nodes, differentiated processing strategies are adopted for transactions with different risk levels. This tiered processing can freeze accounts and repatriate funds for transactions with high node importance assessment values; it can delay transactions and push them to a manual review queue for transactions with medium node importance assessment values; and it can asynchronously mark and monitor transactions with low node importance assessment values ​​and limit their flow. This tiered processing can effectively intercept high-risk transactions to avoid significant asset losses while avoiding excessive control over low-risk, normal transactions, balancing risk control effectiveness and transaction execution efficiency, and meeting the high requirements of smart contract execution in sensitive scenarios such as finance.

[0080] Optionally, the transaction prediction model is δ input to a stable state; The process of processing on-chain data generated by the execution of smart contracts deployed on-chain through a transaction prediction model to obtain node importance assessment values ​​includes: The on-chain data generated by the execution of smart contracts deployed on the chain is divided into time-series characteristic groups, spatial characteristic groups, and behavioral characteristic groups; The temporal feature group, spatial feature group, and behavioral feature group are processed by a bidirectional long short-term memory network (LSTM), a graph convolutional network, and a multilayer perceptron, respectively, to obtain the processing results for each group. The processing results of each group are weighted and fused based on a spatiotemporal attention mechanism to generate a fused feature vector. The node importance evaluation value is obtained based on the fused feature vector.

[0081] In this implementation, the aforementioned transaction prediction model specifically involves δ input to state stability. This model combines the core advantages of elastic recovery mechanism, feature grouping processing, and spatiotemporal attention mechanism, enabling it to efficiently process multi-dimensional on-chain data while ensuring the model's resistance to disturbances and prediction stability, thus adapting to the dynamic and ever-changing needs of on-chain transaction data.

[0082] The Feature Grouping-Spatiotemporal Attention Model is a model that groups on-chain data by features and uses a spatiotemporal attention mechanism to focus on key features. Its core is to achieve accurate feature extraction and fusion of multi-dimensional on-chain transaction data, improving the model's ability to identify transaction patterns. The δ-ISS elastic recovery mechanism is the core mechanism to ensure model stability. Introducing this mechanism can forcibly constrain the spectral radius of the model weights, ensuring that the model can quickly recover to a stable prediction state when encountering data disturbances or abnormal transaction shocks, reducing the impact of abnormal data on node importance assessment results. This model can dynamically adjust the refinement of feature grouping according to changes in the scale of on-chain data, and can also optimize the weight allocation logic of the spatiotemporal attention mechanism according to differences in transaction scenarios, further improving the model's adaptability and prediction accuracy.

[0083] The aforementioned on-chain data contains information across multiple dimensions. Grouping and processing allows for targeted extraction of different types of features, improving data processing efficiency and accuracy. The time-series feature group reflects the dynamic changes in transaction data, and may include transaction amount sequences, transaction frequency, time intervals between adjacent transactions, or derived features such as the sliding window statistical mean or variance of transaction amounts. The spatial feature group characterizes the topological relationships between transaction entities, and may include counterparty type codes, geographical location clustering information of transaction entities, or the connection characteristics of transaction nodes within the blockchain network. The behavioral feature group describes the long-term transaction behavior patterns of transaction entities, and may include historical anomaly scores, session activity, or transaction type preferences.

[0084] Bidirectional LSTM, or Bidirectional Long Short-Term Memory Network, excels at capturing forward and backward dependencies in time-series data. Using bidirectional LSTM to process time-series feature groups can fully uncover the temporal correlation patterns in data such as transaction amounts and frequencies, outputting hidden states that reflect the core information of the time-series features. Graph Convolutional Networks (GCNNs) are adept at processing data with topological relationships. Using GCNNs to process spatial feature groups can construct a transaction relationship graph between transaction entities, transforming spatial topological features into computable feature vectors through graph embedding techniques, outputting the processing results of spatial feature groups. Multilayer Perceptrons (MPPs) are skilled at handling nonlinear mappings of structured data. Using MPPs to process behavioral feature groups can perform nonlinear fitting on features such as historical anomaly scores and session activity, outputting behavioral vectors that characterize the behavioral patterns of transaction entities. During processing, the number of network layers in each processing module can be adjusted according to the data scale of each feature group, and regularization can be used to avoid overfitting.

[0085] Node importance assessment values ​​can be obtained through multi-dimensional weighted calculations, combining assessment indicators such as transaction amount proportion, topological centrality, and anomaly frequency to quantitatively analyze the fused feature vector and output the node importance assessment value. Alternatively, a classification regression model can be used, where the fused feature vector is input into a trained regression model, and the node importance assessment value is output through model mapping. During the acquisition process, the weight allocation of each assessment indicator can be adjusted according to different business risk control needs, and dynamic calibration can be used to correct the deviation of the assessment value, ensuring that the node importance assessment value can truly and accurately reflect the risk level of the transaction node, providing reliable support for the subsequent determination of transaction risk thresholds.

[0086] The technical essence of the above-mentioned δ-ISS constrained elasticity prediction model includes: Control theory guarantees: Force the LSTM weight spectrum radius γ < 0.95 to ensure the upper bound of the recovery time; Dynamic triggering mechanism: node importance.

[0087] In this implementation, a feature grouping-spatiotemporal attention model is constructed to process multidimensional transaction data. A multi-task learning framework is used to simultaneously optimize sequence reconstruction and state prediction, and a delta-ISS elastic recovery mechanism is introduced to ensure the model's resilience to disturbances. In some optional implementations, a dynamic threshold triggering system can also be designed to achieve precise risk control response. Subsequently, a federated learning collaborative network can be established to break down data silos.

[0088] For example, the original transaction characteristics can be divided into three groups—temporal, spatial, and behavioral—for independent processing: (1) Time-series feature group: handles the inherent dynamic changes of transactions, including: Transaction amount series (sliding window statistics: mean / variance); Transaction frequency (number of times per unit of time); Time interval (EMA smoothing value of adjacent transactions Δt); Processing module: Bidirectional LSTM, captures forward and backward dependencies, outputs hidden states: ; (2) Spatial Feature Group: Characterizes the topological relationships between trading entities, including: Counterparty type encoding (one-hot vector for financial institutions / individuals / exchanges); Geographic location clustering (IP-based GeoHash grid coding); Processing module: Graph Convolutional Network (GCN), constructs a transaction relationship graph (node ​​= address, edge = transaction), outputs graph embedding: ; (3) Behavioral characteristic group: describes the subject's long-term behavioral patterns, including: Historical anomaly score (percentage of fraudulent transactions in the past 90 days); Session activity (current session transaction frequency / duration); Processing module: Multilayer Perceptron (MLP), output behavior vector: .

[0089] Furthermore, a two-dimensional attention mechanism can be used to dynamically weight feature importance: Temporal attention focuses on key transaction moments (such as peak periods of large transfers), spatial attention identifies high-risk feature groups (such as clustering of abnormal counterparties), and the final output is a fused vector h_fused. ; Where α_t is the time weight, β_g is the feature group weight, and h_{t,g} is the feature vector at time t and spatial location g, which significantly improves the efficiency of feature representation.

[0090] In some alternative implementations, a dual-task collaborative optimization architecture can be constructed: The reconstruction task receives the unified vector h_fused output from the feature extraction layer and reconstructs the original transaction sequence through the decoder. It calculates the mean squared error (MSE) with the input X. Its core principle is to force the model to retain complete input information, providing a differentiable verification metric for δ-ISS stability, while filtering out 56.3% of data noise (such as abnormal fluctuations), forming the cornerstone of model stability.

[0091] Furthermore, by sharing the same feature vector h_fused across prediction tasks, future multi-scale risk states can be output: Short-term (TCN branch): The specific indicators for the next three steps (amount, frequency, counterparty type, and geographical risk score) directly drive real-time risk control; the LSTM model will first perform preliminary processing on the time series data to extract local time features, and then pass these features as input to the TCN branch, which will further mine long-term time features.

[0092] Long-term (GNN-Trans branch): A comprehensive risk trend value (0-1) for the next 30 steps, identifying systemic risks. The time-series features extracted by the LSTM model can be fused with the graph structure features extracted by the GNN-Trans branch. For example, the features output by the LSTM can be used as node features input into the GNN-Trans branch, and graph convolution operations can be used to update the node features, thereby capturing the relationships between nodes.

[0093] In this implementation, the "prediction-as-interception" efficient response can be achieved through joint optimization of Huber loss (noise resistance) and quantile loss (capturing extreme values).

[0094] Furthermore, conflicting task gradients can be resolved using the projecting conflicting gradients (PCGrad) method: calculating the angle between the task gradients. (θij) Let represent the angle between the gradients of task i and task j (used to measure the directional relationship between the gradients of the two tasks during optimization). Then, project the conflicting gradient: , in, and gi′ are the gradients of task i and task j, respectively, and gi′ is the projected gradient. This eliminates the conflict between the two gradients, enabling the model to better optimize multiple tasks simultaneously.

[0095] Furthermore, the joint loss function can be as follows: Huber, experiments show The F1 score is optimal at this time.

[0096] Furthermore, the elastic recovery mechanism can be understood as a guarantee of the δ-ISS theory, constraining the spectral radius γ of the LSTM weight matrix based on incremental input state stability theory (δ-ISS). The reconstruction task reconstructs the input sequence through the decoder, and its reconstruction error, acting as a differentiable stability verifier, can directly drive the constraint of the δ-ISS theory on the LSTM weight matrix. The upper bound of the recovery time is defined as follows: ,in, For the state change or perturbation, γ is the spectral radius of the LSTM weight matrix, and ε is the tolerance error.

[0097] By constraining γ<1, we ensure exponential convergence after perturbation.

[0098] In some alternative implementations, a spectral norm regularization term can be added during training: , This represents regularization loss, which is a portion of the total model loss and is used to penalize the model's complexity. β is a hyperparameter used to control the weight of the regularization term in the total loss. A smaller β value means a smaller penalty for regularization, while a larger β value means a stronger regularization effect; This represents the square of the L2 norm of the weight matrix W. The L2 norm (also known as the Euclidean norm) is the square root of the sum of the squares of the vector elements.

[0099] Dynamically adjust the learning rate to ensure that the spectral radius γ of the LSTM weight matrix strictly satisfies The δ-ISS stability condition.

[0100] In the 50% noise injection test, the δ-ISS theory was transformed into an engineering-monitorable stability index by mathematically explicitly relating the decoder reconstruction error to the LSTM weight spectrum radius ($R^2=0.93$), providing millisecond-level self-healing capability certification for the prediction model. The model recovery time was shortened from 320ms to 152ms (a 52.5% improvement), and the prediction bias was reduced to 1 / 3 of that of the traditional model.

[0101] Furthermore, a five-dimensional node importance assessment system can be established: The five-dimensional node importance assessment system is a strategic application extension of prediction tasks: the future transaction status (amount, frequency, counterparty, etc.) output by the prediction task drives the dynamic weighting of importance indicators in real time. Simultaneously, the importance assessment results are fed back to revise the prediction model, assigning higher prediction weights to high-importance nodes, forming a closed-loop optimization chain of "prediction → assessment → focusing → re-prediction." Ultimately, trigger thresholds are generated based on dynamic importance, reducing the Auto-Trigger false alarm rate by 72% (6.3% in high-frequency financial fraud scenarios vs. 22.7% with traditional methods). The formula can be expressed as follows: in This includes: transaction amount percentage (25%), anomaly frequency (20%), topological centrality (30%), characteristic variance (15%), and temporal correlation (10%). This refers to a specific transaction node (representing a transaction entity in the blockchain network, possessing specific transaction characteristics and a network topology location). This represents the weight of the k-th indicator. Represents a node The overall importance assessment value.

[0102] For example, in the five-dimensional node importance assessment of a financial institution's smart contract payment system: Transaction Amount Percentage (25%): A single transaction amount reached 5 million yuan, far exceeding the system's average transaction amount, indicating its importance in terms of capital scale. Significant - Abnormal Frequency (20%): This account frequently engaged in large-scale transactions within a short period, exceeding the normal frequency. System monitoring revealed that this account had as many as 10 such abnormal transactions per month, a significantly high frequency.

[0103] Topology centrality (30%): The account occupies a central position in the flow of funds, connecting multiple important counterparties. It is a key node in multiple transaction chains, and its removal will significantly reduce network connectivity, indicating that it occupies a critical position in the transaction network topology.

[0104] Feature Variance (15%): Transaction characteristics exhibit high diversity, including different transaction types, amount ranges, and time intervals. The account's transaction feature vector has a large standard deviation, indicating complex and variable trading behavior patterns.

[0105] Time-series correlation (10%): The trading time distribution closely matches periods of abnormal market fluctuations, indicating a significant time-series dependence in the trading. The strong correlation between the account's trading time and market volatility further increases the trading risk.

[0106] Furthermore, the system calculates a comprehensive risk score for the transaction based on a five-dimensional node importance assessment system. Since the transaction exhibits high-risk characteristics across multiple dimensions, the system determines that the transaction carries significant risk. This triggers the smart contract's Auto-Trigger mechanism to intercept the transaction and initiate a risk warning process. Simultaneously, the system records relevant information about the transaction for subsequent manual review and further investigation. Through this comprehensive assessment method, financial institutions can effectively identify and prevent potential financial risks, ensuring the safe and stable operation of the payment system.

[0107] In some alternative implementations, the trigger threshold can be dynamically calculated as follows: To reconstruct the error standard deviation, experiments showed that this mechanism increased the detection rate of high-frequency, small-amount financial fraud attacks from 72.3% to 95.6%, and reduced the false alarm rate to 6.2%.

[0108] In some alternative implementations, node importance can be based on dynamically calculated values. Generate risk threshold When real-time transaction characteristics When the amount / frequency exceeds this threshold, an interception decision is triggered, and this is verified in conjunction with related indicators (such as...). Or the adversary is in the blacklist), through multi-factor and logic (such as... This reduces the false trigger rate to 0.07%, a 97% reduction compared to single-factor decision-making.

[0109] : Represents the importance metric of node j; : Represents the change in the importance metric of node j; The trigger threshold for node j; : Standard deviation of reconstruction error related to node j.

[0110] Furthermore, the off-chain prediction service can submit transaction hashes and zero-knowledge risk proofs to the smart contract. The contract schedules verification nodes to complete Groth16 protocol verification (≤15ms). Once successful, the Auto-Trigger module executes tiered interception: High risk ( ): Freeze the account and return funds within 50ms (call safeTransferFrom); Medium risk ( ): Delay the transaction and push it to the manual review queue; Low risk ( ): Asynchronous tagging, monitoring, and rate limiting (e.g., reducing the daily transaction limit); the entire process execution latency is ≤80ms, meeting financial-grade real-time requirements.

[0111] Furthermore, a self-verifying security mechanism can be included, employing dual-signature arbitration (allowing for interception commands to be signed by 2 / 3 of the verification nodes) and a time-lock challenge (allowing the frozen party to submit a ZK proof appeal within 15 minutes). Simultaneously, interception evidence (operation logs, risk proofs) is stored in IPFS, and the evidence hash is uploaded to the blockchain to ensure auditable and tamper-proof operations. Any accidental triggering can be appealed for unfreezing within 24 hours, and the system automatically compensates users for losses through an interception liability insurance pool.

[0112] In the smart contract execution method of this application embodiment, by clarifying the specific type of the transaction prediction model and refining the process for obtaining the node importance assessment value, the entire process of on-chain data processing, from feature grouping, dedicated processing, feature fusion to assessment value output, is standardized. The feature grouping-spatiotemporal attention model, which introduces the δ-ISS elastic recovery mechanism, can efficiently process multi-dimensional on-chain data while ensuring prediction stability, adapting to scenarios with dynamically changing on-chain data. The four-step process for obtaining the node importance assessment value, through targeted feature processing and fusion, ensures the accuracy of the assessment results, adapting to the risk control needs of different business scenarios, and providing solid technical support for the subsequent determination of dynamic risk thresholds and the triggering of risk interception commands.

[0113] Optionally, obtaining the transaction risk threshold based on the node importance assessment value includes: obtaining the standard deviation of the reconstruction error of the on-chain data; The transaction risk threshold is obtained based on the node importance assessment value and the standard deviation of the reconstruction error.

[0114] In the smart contract execution method of this application embodiment, by clarifying the specific type of the transaction prediction model, the process of obtaining the node importance assessment value is refined, realizing the standardization of the entire process of on-chain data processing from feature grouping, dedicated processing, feature fusion to assessment value output. The feature grouping-spatiotemporal attention model with the introduction of the δ-ISS elastic recovery mechanism can ensure prediction stability while efficiently processing multi-dimensional on-chain data; the four-step node importance assessment value acquisition process, through targeted feature processing and fusion, ensures the accuracy of the assessment results, providing solid technical support for the subsequent determination of dynamic risk thresholds and the triggering of risk interception commands.

[0115] Optionally, the method further includes: Establish a federated learning collaborative network for the collaborative optimization of transaction prediction models; The identity legitimacy and local training capability of each blockchain node applying to access the federated learning collaboration network are verified. The nodes that pass the verification are determined as nodes participating in the collaboration. The nodes participating in the collaboration are used to independently train the transaction prediction model based on local on-chain data and generate corresponding local model gradients. Homomorphic encryption technology is used to encrypt the local model gradients of all participating nodes. Obtain the gradient contribution weight of each participating collaborative node, and perform a weighted aggregation operation on the local model gradients of all participating collaborative nodes after encryption based on the gradient contribution weight to generate the global model gradient; The global model gradient is distributed to each participating node so that each participating node updates its local transaction prediction model based on the global model gradient.

[0116] In this implementation, the federated learning collaboration network is a collaborative optimization network built by multiple blockchain nodes based on the federated learning concept. Its core objective is to allow nodes to jointly participate in the training and optimization of a transaction prediction model without sharing local on-chain data. This ensures data privacy while integrating the core features of data from multiple nodes, thereby improving model performance. When building this network, a consortium blockchain architecture can be adopted, incorporating core blockchain nodes with model training capabilities and clearly defining the collaboration permissions and data interaction rules for each node. Alternatively, a distributed networking mode can be used, allowing qualified blockchain nodes to autonomously connect and participate in collaboration. The network architecture can be dynamically adjusted according to the number of nodes to ensure network stability and scalability. After the network is built, participating nodes can interact with each other through encrypted communication protocols, ensuring information security during the collaboration process.

[0117] After establishing a federated learning collaboration network, the identity legitimacy and local training capabilities of each blockchain node applying to access the network need to be verified. Only nodes that pass the verification can participate in the collaborative optimization of the model. This verification step can ensure the security and efficiency of the collaboration network and prevent unauthorized nodes from accessing the network or nodes with insufficient capabilities from affecting the model optimization effect.

[0118] Identity verification confirms the true identity and access permissions of the applicant node, ensuring it is a compliant blockchain node. Verification methods can include digital signature verification, confirming identity legitimacy through the node's pre-registered digital signature; or node qualification review, verifying the node's institutional qualifications and blockchain access registration information to ensure legality and compliance. Local training capability verification confirms that the applicant node possesses the hardware and software conditions to independently train a transaction prediction model. Verification can include hardware configurations such as processor performance and memory capacity to ensure it can handle model training tasks; it can also include software conditions such as data processing capabilities and model training algorithm support capabilities to ensure it can complete model training based on local on-chain data and generate effective local model gradients. Once the participating nodes are determined, the network will assign them a unique collaboration identifier for subsequent gradient interaction and permission management.

[0119] The core responsibility of participating nodes is to independently train a transaction prediction model based on local on-chain data and generate corresponding local model gradients. The local model gradient is the amount of model parameter update obtained after the node trains the model with local data. It can reflect the contribution of local data to model optimization. Each participating node completes the training process independently, does not leak local on-chain data to other nodes, and only outputs local model gradients for collaborative optimization.

[0120] Gradient contribution weight is a quantitative value used to quantify the degree of contribution of each participating collaborative node to the global model optimization. It can reflect the impact of factors such as the quality of local data and the model training effect on collaborative optimization. When obtaining this weight, it can be calculated in combination with indicators such as the amount of local data and the data quality anomaly rate of the node. The larger the amount of data and the lower the anomaly rate of the node, the higher the gradient contribution weight can be. Alternatively, it can be calculated in combination with indicators such as the training accuracy and generalization ability of the local model of the node. The better the training effect of the node, the higher the gradient contribution weight can be, thereby incentivizing each node to provide high-quality data and accurate training results.

[0121] Homomorphic encryption is an encryption technology that, after processing encrypted data, yields a decrypted result that is identical to the result of processing unencrypted data. Its core advantage is that it can complete the computation without decrypting the data, thus ensuring data privacy. When using this technology to encrypt local model gradients, the Paillier homomorphic encryption algorithm can be used to encrypt the entire local model gradient; alternatively, the ELGamal homomorphic encryption algorithm can be used to encrypt the gradient data in segments. The encrypted gradient data can only be decrypted within the collaborative network using a dedicated key, ensuring that the gradient data is not illegally stolen or tampered with.

[0122] In this implementation, cross-institutional collaboration within a federated learning framework is possible, and, firstly, privacy-preserving training is possible: Each financial institution locally trains its core LSTM model to perform prediction tasks, sharing only the model gradients (not the original data): global_grad = FedAvg(local_grad_1, local_grad_2, ...) # Gradient aggregation Wherein, global_grad: global gradient, representing the aggregated gradient, used to update global model parameters.

[0123] FedAvg: Federated Averaging algorithm, used to aggregate the local gradients calculated by each client (or participant).

[0124] local_grad_1, local_grad_2, ...: Local gradients, representing the gradients calculated by each client based on its own data.

[0125] Furthermore, node data quality can be dynamically quantified through local reconstruction tasks: Among them, the abnormality rate To measure the credibility of the data; Effective data volume The size of the clean data retained after filtering low-confidence samples; The two processes are performed locally to generate quality certificates. Upload.

[0126] in, : Abnormality rate; n: Number of samples; The k-th sample; The estimated or predicted value of the k-th sample; : Threshold, used to measure the degree of anomaly in the data; std(X): Standard deviation of dataset X; : Valid data volume; : Confidence level of the k-th sample; Quality certificate: A certificate used to verify the quality of data; SHA3: A cryptographic hash function used to generate the hash value of data.

[0127] Weights are deeply tied to federation: Central server Assign gradient contribution weights and aggregate global gradients. in, Automatic suppression of highly abnormal nodes ( ), causing the aggregation gradient deviation Improved model convergence accuracy (measured Federated F1 reached 91.3%, compared to Equal Aggregation +6.1pp). at the same time Ensure information density and prevent small, high-quality nodes from being marginalized (e.g., when bank A has a weight of 0.28, F1 increases by 8.7%).

[0128] in, : Weight, representing the weight of node i in the global gradient aggregation of the federated learning; : Global gradient, representing the aggregated global gradient; : The gradient of node i; Error term (Error), in the context, represents the deviation or error of the i-th gradient.

[0129] Furthermore, weights can be assigned based on the quality of node data: Suppress the pollution of the global model by abnormal data sources.

[0130] Furthermore, in some alternative implementations, the weight formula for the gradient quality weighting mechanism of federated learning can be as follows: w_i = (1 - anomaly_rate_i) * data_volume_i Privacy can be protected by transmitting gradients using Paillier homomorphic encryption.

[0131] In the smart contract execution method of this application embodiment, a complete process of building a collaborative network, verifying node qualifications, encrypting gradient data, aggregating global gradients, and updating the local model is adopted to achieve multi-node collaborative optimization of the transaction prediction model. This not only ensures the privacy and security of the local on-chain data of each node, but also integrates the core data features of multiple nodes, improves the model's prediction accuracy and anti-disturbance capability, and enables the transaction prediction model to better adapt to the smart contract execution needs of multiple institutions and multiple scenarios. It also provides more reliable model support for the accurate acquisition of subsequent node importance assessment values ​​and the reasonable determination of transaction risk thresholds.

[0132] Optionally, after performing privacy logic verification on the smart contract to be deployed based on the first specification, the method further includes: If the privacy logic verification of the smart contract to be deployed fails, the artificial intelligence repair engine is activated to generate a repair solution containing privacy obfuscation code; After obtaining the privacy transaction package, obtaining the corresponding zero-knowledge proof based on the privacy transaction package, and deploying the smart contract to be deployed on the chain after the privacy authorization and privacy logic verification have passed, the process further includes: Monitor the smart contracts deployed on the blockchain.

[0133] In this implementation, after performing privacy logic verification on the smart contract to be deployed based on the first specification, if the verification fails, that is, if the privacy logic of the smart contract to be deployed does not meet the judgment criteria of the first specification and there is a privacy leak or compliance vulnerability, then the artificial intelligence repair engine needs to be activated to generate a repair solution containing privacy obfuscation code. This step can quickly locate and make up for privacy logic vulnerabilities, improve the contract verification pass rate, and reduce the cost of manual repair.

[0134] Privacy obfuscation code is a code snippet used to patch privacy logic vulnerabilities and enhance privacy protection. Its core function is to encrypt or obfuscate logic in the contract that may leak sensitive information, ensuring the contract complies with the first specification requirements after repair. The repair solution is a complete solution including privacy obfuscation code, vulnerability location instructions, and repair operation guidelines. When generating a repair solution, the AI ​​repair engine can generate privacy obfuscation code embedding multinomial commitments to address vulnerabilities where transaction amounts are output in plaintext, converting the plaintext amount into an irreversibly derivable commitment value. It can also generate temporary address generation code based on hash algorithms to address vulnerabilities where real addresses can be associated with the contract, achieving address obfuscation. After the repair solution is generated, relevant personnel can modify the code of the smart contract to be deployed according to the solution, resubmit for privacy logic verification, and continue until verification is successful.

[0135] Privacy logic specifications can be designed based on the Coq proof assistant using smart contract formal verification algorithms, and a semantic conversion toolchain from Solidity to Coq can be built to achieve fully automated verification of privacy protection logic. Specifically, Solidity contracts can be converted into Coq-verifiable intermediate representations (IRs) using a formal verification toolchain and a custom compiler, Sol2Coq.

[0136] Privacy operation identification: Automatically flag privacy-related functions such as pedersen_commitment and temp_addr_generate.

[0137] Context-aware conversion: Preserves variable scope and state dependencies (e.g., msg.sender is mapped to the Coq address type).

[0138] Example conversion code is as follows: Definition transfer (from: address) (to: address) (amt: nat) (r:Rand) := require (balances[from] >= amt); balances[from] := balances[from] - amt; balances[to] := balances[to] + amt; emit Transfer(from, to, pedersen_commitment(amt, r)). This definition is a formal modeling of smart contract transfer functions in Coq. The core of it is to embed Pedersen commitments in the transfer event to hide the real amount.

[0139] In some alternative implementations, rule base matching can be achieved through predefined privacy vulnerability remediation rules (such as unencrypted amount exposure → inserting a Pedersen commitment).

[0140] AI-assisted patching: It can train models based on historical vulnerability data and generate candidate patch codes.

[0141] Example of the fix is ​​as follows: diff emit Transfer(msg.sender, to, amount); emit Transfer(msg.sender, to, pedersenCommit(amount, r)); This diff demonstrates a key privacy modification: replacing the transfer event that directly exposes the transaction amount with a version that embeds the Pedersen commitment, thereby hiding the real amount.

[0142] Furthermore, a runtime monitoring module may be included for dynamic verification. For example, the on-chain monitoring contract configuration may be as follows: contract PrivacyMonitor { mapping(bytes32 => bool) public committed_hashes; function verifyRuntimeCompliance(bytes32 txHash, bytes calldataproof) public { require(!committed_hashes[txHash], "Duplicate transaction"); (bool success, ) = address(verifier).call(proof); require(success, "Runtime verification failed"); committed_hashes[txHash] = true; } } The aforementioned contract can serve as a core component for dynamic monitoring in a combined static and dynamic formal verification system, used to verify the privacy compliance of transactions during on-chain execution and to prevent duplicate submissions.

[0143] Monitoring logic: Before a transaction is recorded on the blockchain: verify the consistency between the formal proof and the off-chain Coq verification results.

[0144] After execution: Check whether the status change complies with the privacy policy (e.g., whether the address temporaryization is effective).

[0145] In some alternative implementations, a dynamic-static combined formal verification system may include: Static verification: Coq defines 10 privacy rules (such as address non-association). tx1 tx2, temp_addr1≠temp_addr2 → real_addr1≠real_addr2); Dynamic monitoring: On-chain contracts intercept illegal transactions in real time (such as the exposure of unencrypted amounts).

[0146] In the smart contract execution method of this application embodiment, the artificial intelligence repair engine can quickly patch privacy logic vulnerabilities in the smart contract to be deployed, improving contract verification efficiency; continuous monitoring after on-chain ensures privacy compliance during smart contract operation and timely prevents privacy risks during operation. The two work together to further improve the full lifecycle management of smart contract privacy protection, ensuring that smart contracts strictly comply with the privacy protection requirements of the first specification from before deployment to after deployment, adapting to the smart contract execution needs of various sensitive scenarios.

[0147] In other alternative implementations, a verifiable privacy smart contract engine may be included to integrate the above modules into a layered protocol stack, supporting a closed-loop process of privacy protection, formal verification, and dynamic execution, and compatible with mainstream blockchain virtual machines (EVM / WASM).

[0148] In some alternative implementations, reference may be made to Figure 5The architecture comprises five modules forming a closed loop: a feature processing layer extracts spatiotemporal correlation features → a multi-task model learns transaction patterns → an elastic mechanism ensures prediction stability → a dynamic threshold generates trigger conditions → a federated framework enables cross-institutional collaborative evolution. In tests on the SWAT financial fraud dataset, this architecture achieved an F1 score of 91.3% (a 12.1% improvement over traditional LSTM), reduced the false positive rate by 67%, and shortened recovery time by 52.5%, providing industrial-grade risk control capabilities for blockchain smart contracts.

[0149] Furthermore, the smart contract execution method in this application embodiment has the following technical advantages: By hiding both the transaction amount and the address, and using a layered zero-knowledge proof architecture (LDE multinomial-bound dynamic hash chain), the probability of temporary address collisions is reduced to 10^(-6) (Monero's solution is 10^(-3)), while also resisting quantum attacks (SHA3-256). Significantly optimized on-chain verification efficiency: Gas consumption for proof generation is reduced by 42% (1,200,000 → 700,000 Gas), and verification coverage is increased to 95% (compared to only 20% for traditional tools). This completely solves the single-dimensional privacy protection deficiency in related technologies, thereby achieving a double leap in both privacy security and efficiency.

[0150] Furthermore, by introducing the δ-ISS elastic recovery mechanism (forcing the LSTM weight spectrum radius γ < 0.95), the recovery time is compressed to 152ms under 50% noise interference (speeding up by 52.5%), and the prediction bias is reduced by 63%. The dynamic triggering system, based on five-dimensional node importance assessment (amount proportion + abnormal frequency + topological centrality, etc.), has boosted the detection rate of high-frequency financial fraud attacks to 95.6% (72.3% for traditional models) and reduced the false alarm rate to 6.2% (18.7% for static threshold schemes), thereby improving the anti-interference and accuracy of the prediction model.

[0151] Furthermore, federated learning employs anomaly rate-data volume weighted aggregation w_i=(1-α_i)*v_i, achieving an F1 score of 91.3% in joint training with 5 institutions (the highest single institution score is 83.5%, +9.3%), and preventing 78% of anomalous data pollution; thus achieving a qualitative leap in cross-institutional collaboration efficiency.

[0152] Please see Figure 6 , Figure 6 This is a schematic diagram of a smart contract execution device 200 provided in an embodiment of this application. As shown in the figure, the smart contract execution device 200 includes: The acquisition module 210 is used to acquire a privacy transaction package, acquire a corresponding zero-knowledge proof based on the privacy transaction package, and send the privacy transaction package and the zero-knowledge proof to the on-chain verification node, wherein the privacy transaction package is constructed based on transaction data; Verification module 220 is used to construct a first specification based on the zero-knowledge proof, obtain a smart contract to be deployed, perform privacy logic verification on the smart contract to be deployed based on the first specification, and authorize the deployment of smart contracts that pass the privacy logic verification to be deployed on the chain. The processing module 230 is used to process the on-chain data generated by the execution of the smart contract deployed on the chain through a transaction prediction model, so as to obtain the node importance assessment value and determine the transaction risk threshold based on the node importance assessment value. Trigger module 240 is used to trigger an interception command when the risk value corresponding to the transaction feature data exceeds the transaction risk threshold, wherein the transaction feature data is feature data extracted from the transaction data.

[0153] Optionally, the acquisition module 210 can also be used for: Generate a random number with obfuscated amount and a random number with obfuscated address based on the transaction data; A multinomial commitment is used to encode the transaction amount in the transaction data and the amount-mixed random number to generate an amount commitment value; Based on the hash algorithm, a proof public parameter is generated by combining the real user address in the transaction data, the address confusion random number and the block height corresponding to the transaction timestamp, and a temporary address is generated based on the proof public parameter. The promised amount and the temporary address are hashed together to generate an integrity proof; The privacy transaction package is constructed based on the transaction data, the temporary address, and the integrity proof.

[0154] Optionally, the first specification includes at least one of the following: compliance with amount concealment, address non-association, and resistance to replay attacks; The on-chain verification nodes are used to verify the integrity of the privacy transaction package and perform tiered processing on the transaction based on the node importance assessment value.

[0155] Optionally, the transaction prediction model is δ input to a stable state; The processing module 230 can also be used for: The process of processing on-chain data generated by the execution of smart contracts deployed on-chain through a transaction prediction model to obtain node importance assessment values ​​includes: The on-chain data generated by the execution of smart contracts deployed on the chain is divided into time-series characteristic groups, spatial characteristic groups, and behavioral characteristic groups; The temporal feature group, spatial feature group, and behavioral feature group are processed by a bidirectional long short-term memory network (LSTM), a graph convolutional network, and a multilayer perceptron, respectively, to obtain the processing results for each group. The processing results of each group are weighted and fused based on a spatiotemporal attention mechanism to generate a fused feature vector. The node importance evaluation value is obtained based on the fused feature vector.

[0156] Optionally, the processing module 230 can also be used for: Obtain the standard deviation of the reconstruction error of the on-chain data; The transaction risk threshold is obtained based on the node importance assessment value and the standard deviation of the reconstruction error.

[0157] Optionally, the smart contract execution device 200 can also be used for: Monitor node load and task execution status in real time, and adjust smart contract execution plans based on monitoring results.

[0158] Optionally, the smart contract execution device 200 can also be used for: Establish a federated learning collaborative network for the collaborative optimization of transaction prediction models; The identity legitimacy and local training capability of each blockchain node applying to access the federated learning collaboration network are verified. The nodes that pass the verification are determined as nodes participating in the collaboration. The nodes participating in the collaboration are used to independently train the transaction prediction model based on local on-chain data and generate corresponding local model gradients. Homomorphic encryption technology is used to encrypt the local model gradients of all participating nodes. Obtain the gradient contribution weight of each participating collaborative node, and perform a weighted aggregation operation on the local model gradients of all participating collaborative nodes after encryption based on the gradient contribution weight to generate the global model gradient; The global model gradient is distributed to each participating node so that each participating node updates its local transaction prediction model based on the global model gradient.

[0159] Optionally, the smart contract execution device 200 can also be used for: If the privacy logic verification of the smart contract to be deployed fails, the artificial intelligence repair engine is activated to generate a repair solution containing privacy obfuscation code; After obtaining the privacy transaction package, obtaining the corresponding zero-knowledge proof based on the privacy transaction package, and deploying the smart contract to be deployed on the chain after the privacy authorization and privacy logic verification have passed, the process further includes: Monitor the smart contracts deployed on the blockchain.

[0160] The smart contract execution device provided in this application embodiment can achieve... Figure 1 The various processes implemented in the method embodiments shown achieve the same technical effects, and will not be described again here to avoid repetition.

[0161] For details, see Figure 7 As shown in the figure, this application embodiment also provides an electronic device, including a bus 301, a transceiver 302, an antenna 303, a bus interface 304, a processor 305, and a memory 306.

[0162] Processor 305, used for: Obtain a privacy transaction package, obtain a corresponding zero-knowledge proof based on the privacy transaction package, and send the privacy transaction package and the zero-knowledge proof to the on-chain verification node, wherein the privacy transaction package is constructed based on transaction data; Based on the zero-knowledge proof, a first specification is constructed to obtain a smart contract to be deployed. Based on the first specification, the smart contract to be deployed is subjected to privacy logic verification. The smart contract to be deployed that passes the privacy logic verification is authorized to be deployed on the chain. The on-chain data generated by the execution of smart contracts deployed on the blockchain is processed through a transaction prediction model to obtain a node importance assessment value, and a transaction risk threshold is determined based on the node importance assessment value. If the risk value corresponding to the transaction feature data exceeds the transaction risk threshold, an interception command is triggered. The transaction feature data is feature data extracted from the transaction data.

[0163] exist Figure 7 In this context, a bus architecture (represented by bus 301) is used. Bus 301 can include any number of interconnected buses and bridges, linking various circuits including one or more processors represented by processor 305 and memory represented by memory 306. Bus 301 can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 304 provides an interface between bus 301 and transceiver 302. Transceiver 302 can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by processor 305 is transmitted over a wireless medium via antenna 303, which further receives data and transmits it to processor 305.

[0164] Processor 305 manages bus 301 and general processing, and also provides various functions, including timing, peripheral interface, voltage regulation, power management, and other control functions. Memory 306 can be used to store data used by processor 305 during operation.

[0165] Alternatively, the processor 305 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a complex programmable logic device (CPLD).

[0166] Optionally, the processor 305 can also be used for: Generate a random number with obfuscated amount and a random number with obfuscated address based on the transaction data; A multinomial commitment is used to encode the transaction amount in the transaction data and the amount-mixed random number to generate an amount commitment value; Based on the hash algorithm, a proof public parameter is generated by combining the real user address in the transaction data, the address confusion random number and the block height corresponding to the transaction timestamp, and a temporary address is generated based on the proof public parameter. The promised amount and the temporary address are hashed together to generate an integrity proof; The privacy transaction package is constructed based on the transaction data, the temporary address, and the integrity proof.

[0167] Optionally, the first specification includes at least one of the following: compliance with amount concealment, address non-association, and resistance to replay attacks; The on-chain verification nodes are used to verify the integrity of the privacy transaction package and perform tiered processing on the transaction based on the node importance assessment value.

[0168] Optionally, the transaction prediction model is δ input to a stable state; The processor 305 can also be used for: The process of processing on-chain data generated by the execution of smart contracts deployed on-chain through a transaction prediction model to obtain node importance assessment values ​​includes: The on-chain data generated by the execution of smart contracts deployed on the chain is divided into time-series characteristic groups, spatial characteristic groups, and behavioral characteristic groups; The temporal feature group, spatial feature group, and behavioral feature group are processed by a bidirectional long short-term memory network (LSTM), a graph convolutional network, and a multilayer perceptron, respectively, to obtain the processing results for each group. The processing results of each group are weighted and fused based on a spatiotemporal attention mechanism to generate a fused feature vector. The node importance evaluation value is obtained based on the fused feature vector.

[0169] Optionally, the processor 305 can also be used for: Obtain the standard deviation of the reconstruction error of the on-chain data; The transaction risk threshold is obtained based on the node importance assessment value and the standard deviation of the reconstruction error.

[0170] Optionally, the processor 305 can also be used for: Monitor node load and task execution status in real time, and adjust smart contract execution plans based on monitoring results.

[0171] Optionally, the processor 305 can also be used for: Establish a federated learning collaborative network for the collaborative optimization of transaction prediction models; The identity legitimacy and local training capability of each blockchain node applying to access the federated learning collaboration network are verified. The nodes that pass the verification are determined as nodes participating in the collaboration. The nodes participating in the collaboration are used to independently train the transaction prediction model based on local on-chain data and generate corresponding local model gradients. Homomorphic encryption technology is used to encrypt the local model gradients of all participating nodes. Obtain the gradient contribution weight of each participating collaborative node, and perform a weighted aggregation operation on the local model gradients of all participating collaborative nodes after encryption based on the gradient contribution weight to generate the global model gradient; The global model gradient is distributed to each participating node so that each participating node updates its local transaction prediction model based on the global model gradient.

[0172] Optionally, the processor 305 can also be used for: If the privacy logic verification of the smart contract to be deployed fails, the artificial intelligence repair engine is activated to generate a repair solution containing privacy obfuscation code; After obtaining the privacy transaction package, obtaining the corresponding zero-knowledge proof based on the privacy transaction package, and deploying the smart contract to be deployed on the chain after the privacy authorization and privacy logic verification have passed, the process further includes: Monitor the smart contracts deployed on the blockchain.

[0173] It should be noted that the electronic device provided in this application embodiment is a device capable of executing the above-described smart contract execution method. Therefore, all implementation methods in the above-described smart contract execution method embodiments are applicable to this electronic device and can achieve the same or similar beneficial effects. To avoid repetition, this embodiment will not elaborate further.

[0174] This invention also provides an electronic device, including: a processor, a memory, and a program stored in the memory and executable on the processor. When the program is executed by the processor, it implements the various processes of the above-described smart contract execution method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0175] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, this computer program implements the various processes of the above-described smart contract execution method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0176] This application also provides a computer program product, including computer instructions. When these computer instructions are executed by a processor, they implement the various processes of the above-described smart contract execution method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0177] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0178] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0179] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for executing a smart contract, characterized in that, The method includes: Obtain a privacy transaction package, obtain a corresponding zero-knowledge proof based on the privacy transaction package, and send the privacy transaction package and the zero-knowledge proof to the on-chain verification node, wherein the privacy transaction package is constructed based on transaction data; Based on the zero-knowledge proof, a first specification is constructed to obtain a smart contract to be deployed. Based on the first specification, the smart contract to be deployed is subjected to privacy logic verification. The smart contract to be deployed that passes the privacy logic verification is authorized to be deployed on the chain. The on-chain data generated by the execution of smart contracts deployed on the chain is processed by a transaction prediction model to obtain a node importance assessment value, and a transaction risk threshold is determined based on the node importance assessment value. If the risk value corresponding to the transaction feature data exceeds the transaction risk threshold, an interception command is triggered. The transaction feature data is feature data extracted from the transaction data.

2. The method according to claim 1, characterized in that, The transaction data includes the transaction amount and the real user address. Obtaining the privacy transaction package includes: Generate a random number with obfuscated amount and a random number with obfuscated address based on the transaction data; The transaction amount and the amount-confusing random number are encoded using a multinomial commitment to generate an amount commitment value; Based on the hash algorithm, a proof public parameter is generated by combining the real user address, the address confusion random number and the block height corresponding to the transaction timestamp, and a temporary address is generated based on the proof public parameter. The promised amount and the temporary address are hashed together to generate an integrity proof; The privacy transaction package is constructed based on the transaction data, the temporary address, and the integrity proof.

3. The method according to claim 1, characterized in that, The first specification includes at least one of the following: compliance with amount concealment, address non-association, and resistance to replay attacks; The on-chain verification nodes are used to verify the integrity of the privacy transaction package and perform tiered processing on the transaction based on the node importance assessment value.

4. The method according to any one of claims 1 to 3, characterized in that, The transaction prediction model is a feature grouping-spatiotemporal attention model; The process of processing on-chain data generated by the execution of smart contracts deployed on-chain through a transaction prediction model to obtain node importance assessment values ​​includes: The on-chain data generated by the execution of smart contracts deployed on the chain is divided into time-series characteristic groups, spatial characteristic groups, and behavioral characteristic groups; The temporal feature group, spatial feature group, and behavioral feature group are processed by a bidirectional long short-term memory network (LSTM), a graph convolutional network, and a multilayer perceptron, respectively, to obtain the processing results for each group. The processing results of each group are weighted and fused based on a spatiotemporal attention mechanism to generate a fused feature vector. The node importance evaluation value is obtained based on the fused feature vector.

5. The method according to any one of claims 1 to 3, characterized in that, The process of obtaining the transaction risk threshold based on the node importance assessment value includes: Obtain the standard deviation of the reconstruction error of the on-chain data; The transaction risk threshold is obtained based on the node importance assessment value and the standard deviation of the reconstruction error.

6. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Establish a federated learning collaborative network for the collaborative optimization of transaction prediction models; The identity legitimacy and local training capability of each blockchain node applying to access the federated learning collaboration network are verified. The nodes that pass the verification are determined as nodes participating in the collaboration. The nodes participating in the collaboration are used to independently train the transaction prediction model based on local on-chain data and generate corresponding local model gradients. Homomorphic encryption technology is used to encrypt the local model gradients of all participating nodes. Obtain the gradient contribution weight of each participating collaborative node, and perform a weighted aggregation operation on the local model gradient of all participating collaborative nodes after encryption based on the gradient contribution weight to generate the global model gradient; The global model gradient is distributed to each participating node so that each participating node updates its local transaction prediction model based on the global model gradient.

7. The method according to any one of claims 1 to 3, characterized in that, After performing privacy logic verification on the smart contract to be deployed based on the first specification, the method further includes: If the privacy logic verification of the smart contract to be deployed fails, the artificial intelligence repair engine is activated to generate a repair solution containing privacy obfuscation code; After obtaining the privacy transaction package, obtaining the corresponding zero-knowledge proof based on the privacy transaction package, and deploying the smart contract to be deployed on the chain after the privacy authorization and privacy logic verification have passed, the process further includes: Monitor the smart contracts deployed on the blockchain.

8. A smart contract execution device, characterized in that, include: The acquisition module is used to acquire a privacy transaction package, acquire a corresponding zero-knowledge proof based on the privacy transaction package, and send the privacy transaction package and the zero-knowledge proof to the on-chain verification node, wherein the privacy transaction package is constructed based on transaction data; The verification module is used to construct a first specification based on the zero-knowledge proof, obtain the smart contract to be deployed, perform privacy logic verification on the smart contract to be deployed based on the first specification, and authorize the deployment of the smart contract to be deployed on the chain if the privacy logic verification is qualified. The processing module is used to process the on-chain data generated by the execution of smart contracts deployed on the chain through a transaction prediction model in order to obtain a node importance assessment value and determine a transaction risk threshold based on the node importance assessment value. The triggering module is used to trigger an interception command when the risk value corresponding to the transaction feature data exceeds the transaction risk threshold, wherein the transaction feature data is feature data extracted from the transaction data.

9. An electronic device, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the smart contract execution method as described in any one of claims 1 to 7.

10. 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 steps of the smart contract execution method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the steps of the smart contract execution method as described in any one of claims 1 to 7.

Images