Blockchain-based smart contract performance control system, method, device and medium

Abstract

The application provides a smart contract performance control system and method based on a blockchain, and relates to the technical field of smart contracts. The technical solution calls a premonition machine module to access an off-chain trusted data source and obtain external state verification credentials before triggering performance through a compliance risk control layer smart contract. Whether to generate an unlocking signal is determined by combining the security verification operation of digital signatures and timestamps, ensuring that the performance decision is based on real, authoritative and timely external states, effectively preventing the execution of invalid or malicious transactions. At the same time, a log generation module generates structured execution logs containing business metadata and verification credential association identifiers during the operation process and stores them in an encrypted form on the chain, realizing the standardization, traceability and tamper resistance of operation records. In addition, a rule management module introduces a multi-node consensus mechanism to verify the update of the rule library, ensuring the transparency and tamper resistance of rule maintenance and preventing single-point failure or malicious tampering risks.

Description

Technical Field

[0001] This invention relates to the field of smart contract technology, and in particular to a blockchain-based smart contract performance control system, method, device, and medium. Background Technology

[0002] Current blockchain-based smart contract systems commonly suffer from a disconnect between execution logic and external state verification when implementing automated performance. Most solutions rely solely on preset static conditions to trigger operations, making it difficult to effectively acquire and verify authoritative external state information related to the fulfilling entity before execution, such as whether it is in a restricted state or has records of abnormal behavior. Furthermore, existing systems lack a structured recording mechanism for the execution process, resulting in inconsistent operation log formats, missing key elements, and difficulties in efficient identification or reuse by external systems. In addition, the rules used to determine performance conditions are typically deployed and updated by a single node, lacking a multi-party collaborative verification mechanism, which can easily lead to disputes over rule consistency or version control issues. Although some solutions introduce oracles to obtain off-chain data, a comprehensive technical closed loop has not been established to ensure the credibility of data sources, the traceability of execution decisions, and the reliability of rule updates. Summary of the Invention

[0003] The purpose of this invention is to provide a blockchain-based smart contract performance control system, method, device, and medium to solve one or more technical problems existing in the prior art, and at least provide a beneficial option or create conditions that can realize the reliable verification, process traceability, and reliable rule maintenance of smart contracts in complex collaborative scenarios by constructing a collaborative mechanism of external state linkage verification, standardized log generation, and multi-node consensus rule updates, thereby improving the robustness of performance execution and cross-system interoperability.

[0004] On the one hand, this application provides a blockchain-based smart contract performance control system, which is deployed in the contract execution environment of a blockchain node, including an execution layer smart contract configured to perform basic performance operations, a compliance and risk control layer smart contract, an oracle module, a log generation module, and a rule governance module; The compliance and risk control layer smart contract is configured to call the oracle module to access the off-chain trusted data source before triggering the performance operation, so as to obtain the external state verification certificate of the transaction subject, and decide whether to unlock the execution process based on the verification result of the verification certificate. The log generation module is configured to generate a structured execution log containing business operation metadata and the associated identifier of the external status verification certificate during the performance operation, and store the structured execution log in the blockchain in encrypted form. The rule governance module is configured to maintain a rule base for judging performance conditions. Updates to the rule base require multi-node consensus verification by multiple preset governance nodes before they can take effect. The compliance and risk control layer smart contract is also configured to perform a security verification operation: only when the digital signature in the verification credential passes the verification and the timestamp carried by the credential is within a preset valid time window, will an unlock signal be generated to allow the execution layer smart contract to execute; if the verification fails, the execution process will be terminated and the abnormal status will be recorded.

[0005] Furthermore, the specific configuration of the compliance and risk control layer smart contract is as follows: Invoke the oracle module using authenticated access credentials; Receive the query results containing timestamps and electronic verification identifiers returned by the off-chain trusted data source; If the query results show that the transaction entity is in a restricted state or has abnormal behavior records, the process of the execution layer smart contract will be immediately suspended, and a risk warning event containing the reason for suspension will be generated.

[0006] Furthermore, a heterogeneous data cleaning adapter is deployed within the oracle module; The heterogeneous data cleaning adapter is configured as follows: Identify the header information of the original response message returned by the trusted off-chain data source and determine its data encapsulation format; Based on the data encapsulation format, the preset parsing operators stored in the configurable operator library of the oracle module are invoked to parse the original response message and extract key status fields; The key status fields are mapped to standardized data structures that conform to the preset smart contract interface standards; The standardized data structure is digitally signed and encapsulated to generate the external state verification credential.

[0007] Furthermore, the structured execution log includes the following fields: participant identity, operation type, occurrence time, numerical information, verification result, external data source referenced and its verification identifier; The log generation module is also configured to support exporting the structured execution log into a standardized data packet after authorization, so that external systems can read and compare it.

[0008] Furthermore, the log generation module is configured to use an asymmetric encryption algorithm to encrypt and store sensitive numerical information in the structured execution log, generating a ciphertext log corresponding to the public key of the access requester; The log generation module is also configured to de-identify the sensitive numerical information or return the corresponding encrypted log according to the access requester's permission level. The encrypted log can be decrypted by the access requester using a private key held locally on an off-chain terminal to obtain the plaintext.

[0009] Furthermore, the rule governance module is configured to establish a dynamic rule weight model; the governance node is selected from at least one of regulatory agency nodes, core enterprise nodes, and arbitration institution nodes; Upon receiving a performance trigger request, the compliance and risk control layer smart contract is also configured to calculate a comprehensive risk score for the current transaction; The comprehensive risk score is generated by weighted summation based on the weights of abnormal record types and historical violation frequencies in the external state information returned by the oracle module. Based on the comprehensive risk score, the corresponding verification strategy in the rule base is dynamically loaded; When the comprehensive risk score exceeds a preset threshold, the threshold for the number of governance nodes required in the multi-node consensus verification is automatically increased.

[0010] Furthermore, the execution layer smart contract is configured to interact with the compliance and risk control layer smart contract and the log generation module according to the following logic: Upon receiving the unlock signal sent by the smart contract of the compliance and risk control layer, the preset performance transaction execution logic is triggered; At each critical node in the execution of the fulfillment transaction, send the current business operation metadata to the log generation module; When a transaction is completed or terminated abnormally, an execution result identifier is sent to the log generation module to trigger the final on-chain evidence storage operation of the log.

[0011] On the other hand, this application provides a blockchain-based smart contract performance control method, applied to blockchain network nodes, the method comprising: Before triggering the fulfillment operation, a pre-verified transaction containing an oracle callback identifier is generated, and the oracle module is invoked to access the off-chain trusted data source; Receive the verification payload containing digital signature and timestamp returned by the oracle module; Perform a security verification operation to check the validity of the digital signature and the timeliness of the timestamp. If the verification passes, a transaction unlock signal is generated and the performance execution process begins. If the verification fails, the execution process is terminated and the abnormal status is recorded. During execution, a structured execution log containing external data verification identifiers is generated and stored on the blockchain; When it is necessary to update the performance judgment rules, a multi-node consensus process is initiated, and the rule base version is updated after verification and confirmation by multiple preset governance nodes.

[0012] On the other hand, this application provides an electronic device, including: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the blockchain-based smart contract performance control method as described above.

[0013] On the other hand, this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the aforementioned blockchain-based smart contract performance control method.

[0014] The beneficial effects of this invention are as follows: This application provides a blockchain-based smart contract performance control system. This technical solution, through a compliance and risk control layer smart contract, calls an oracle module to access a trusted off-chain data source and obtain external state verification credentials before triggering performance. Combining digital signatures and timestamps for secure verification, it determines whether to generate an unlock signal, ensuring that performance decisions are based on authentic, authoritative, and timely external states, effectively preventing the execution of invalid or malicious transactions. Simultaneously, the log generation module generates a structured execution log containing business metadata and verification credential association identifiers during operation and stores it on the blockchain in encrypted form, achieving standardization, traceability, and tamper-proofing of operation records, significantly improving data auditing capabilities and cross-system interoperability. Furthermore, the rule governance module introduces a multi-node consensus mechanism to verify rule base updates, ensuring the transparency and immutability of rule maintenance and preventing single-point failures or malicious tampering risks. The overall technical solution, through a collaborative closed loop of external verification, internal recording, and rule governance, significantly enhances the security, credibility, and robustness of the smart contract system in complex business environments. This application also provides related methods, devices, and media for the above-mentioned system. The beneficial effects of the related methods, devices, and media are similar to those of the methods, and will not be described in detail here.

[0015] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0016] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.

[0017] Figure 1 This is a structural diagram of the blockchain-based smart contract performance control system provided in this application; Figure 2 This is a flowchart of the blockchain-based smart contract performance control method provided in this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] The present application will be further described below with reference to the accompanying drawings and specific embodiments. The described embodiments should not be considered as limitations on the present application, and all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of the present application.

[0020] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] With the widespread application of blockchain technology, smart contracts, as a core component of decentralized applications, have been widely used in key areas such as finance, supply chain, and digital identity. A smart contract is an automated program running on the blockchain that can automatically execute agreed-upon operations, such as asset transfers, state updates, or service triggers, when preset conditions are met. Its core advantages lie in decentralization, immutability, and automatic execution, effectively reducing trust costs and reliance on intermediaries. However, with the increasing complexity of application scenarios, traditional smart contract systems have exposed numerous technical bottlenecks in actual deployments, particularly in terms of security, compliance, and auditability during the contract fulfillment process.

[0023] In existing technologies, most smart contract systems employ static conditional judgment mechanisms, meaning the contract logic is fixed at deployment time, and execution depends solely on changes in on-chain state. For example, payments are automatically triggered when an account balance reaches a certain threshold. However, such solutions cannot effectively acquire and verify real-world off-chain data, such as user authentication status, credit rating, regulatory compliance, and device operational status. To address this issue, some systems have introduced "oracle" mechanisms to import off-chain data into on-chain contracts. For example, weather data obtained through third-party services can trigger agricultural insurance payouts. However, existing oracle solutions are often single-point access or lack trusted verification mechanisms, leading to issues such as data tampering, high latency, and unreliable sources, making them unsuitable for high-security performance scenarios.

[0024] Furthermore, existing smart contracts generally lack structured logging mechanisms during execution. Most contracts only record simple state changes through event logs, lacking complete records of crucial information such as operational context, external verification criteria, and execution environment. This makes it difficult to trace the authenticity and compliance of operations in the event of disputes or audits. For example, it is impossible to prove whether a payment was completed before a user was listed as a defaulter, or to verify whether rule updates were legally authorized. At the same time, inconsistent log formats and fragmented storage further exacerbate the difficulties of cross-system data interoperability.

[0025] More seriously, the rule base used to control performance conditions in existing systems is usually maintained unilaterally by the contract deployer. Rule updates do not require consensus among multiple parties, which can easily lead to problems such as abuse of permissions, rule tampering, or version inconsistencies. For example, the platform may modify rates or access conditions without notifying users, undermining the fairness and transparency of the system. Although some solutions attempt to introduce governance contracts, they lack deep integration with the performance process and cannot achieve coordinated control between rule updates and execution verification.

[0026] In summary, existing smart contract systems have significant shortcomings in areas such as external data verification, execution process recording, and rule governance mechanisms, making it difficult to meet the comprehensive requirements for security, compliance, auditability, and decentralized governance in complex business scenarios. Especially in applications involving multi-party collaboration, high-value transactions, or stringent regulatory requirements, existing technologies are no longer sufficient to effectively support trusted performance. There is an urgent need for a new smart contract performance control system that integrates external state verification, structured log recording, and consensus-driven rule governance.

[0027] To address the aforementioned issues, this application proposes a blockchain-based smart contract performance control system, the core of which lies in constructing a collaborative execution architecture that integrates external state linkage verification, structured log auditing, and decentralized rule governance.

[0028] This system deploys a compliance and risk control layer smart contract within the contract execution environment. Before triggering basic performance operations, this contract proactively calls an oracle module to obtain external state verification credentials from a trusted off-chain data source. These credentials are then combined with digital signatures and timestamps for security verification. Only when the credentials are valid is an unlock signal generated to allow the execution layer smart contract to continue operating, thus achieving trusted verification of the execution prerequisites. Simultaneously, the system introduces a log generation module that automatically generates structured execution logs containing business operation metadata and verification credential association identifiers during the performance process. These logs are persistently stored in encrypted form on the blockchain, ensuring traceability and tamper-proof operation.

[0029] Furthermore, the rule governance module maintains the performance rule base, and stipulates that all rule updates must undergo consensus verification by multiple preset governance nodes before taking effect, effectively preventing single-point control and rule tampering risks. The overall technical solution, through multi-module collaboration, achieves trusted management of the entire lifecycle of smart contracts, from pre-execution verification and process recording to rule maintenance.

[0030] First, the blockchain-based smart contract performance control system provided in this application will be described in detail below with reference to the accompanying drawings.

[0031] Reference Figure 1 The blockchain-based smart contract performance control system provided in this application embodiment is deployed in the contract execution environment of a blockchain node. It includes an execution layer smart contract configured to perform basic performance operations, a compliance and risk control layer smart contract, an oracle module, a log generation module, and a rule governance module. Before performing basic performance operations, the system can use an oracle to obtain and verify trusted off-chain data to ensure compliance. Simultaneously, it generates structured encrypted logs to achieve full-process traceability and maintains the update of the rule base through a multi-node consensus mechanism. This comprehensively enhances the security, trustworthiness, and robustness of the smart contract performance process within the blockchain node environment.

[0032] In some embodiments of this application, the compliance and risk control layer smart contract is configured to: before triggering the performance operation, call the oracle module to access the off-chain trusted data source to obtain the external state verification certificate of the transaction subject, and decide whether to unlock the execution process based on the verification result of the verification certificate.

[0033] By leveraging smart contracts in the compliance and risk control layer, a proactive security filtering and decision-making mechanism is constructed. This breaks away from the closed nature of traditional smart contracts that rely solely on on-chain data, incorporating real-world authoritative status (such as user credit, regulatory lists, or device status) into the performance evaluation process. Through this mechanism, the system can accurately identify and intercept non-compliant or high-risk transactions before funds or assets are transferred, achieving a shift from passive auditing to proactive defense and significantly improving the compliance and security of contract execution.

[0034] In some embodiments of this application, the log generation module is configured to: generate a structured execution log containing business operation metadata and an external status verification credential associated identifier during the performance operation, and store the structured execution log in encrypted form on the blockchain.

[0035] By establishing a complete, tamper-proof, and machine-readable audit trail system through the log generation module, the problem of missing contextual information in traditional blockchain transactions is solved. By associating and binding business metadata with external verification credentials, this module ensures that every on-chain operation is traceable, providing a reliable chain of evidence for subsequent regulatory audits, dispute arbitration, and cross-system data interactions, thereby significantly enhancing the traceability and transparency of the entire performance process.

[0036] In some embodiments of this application, the rule governance module is configured to maintain a rule base for judging performance conditions, and the update of the rule base can only take effect after being verified by multiple preset governance nodes through multi-node consensus.

[0037] Through the rules governance module, a decentralized trust mechanism for rule changes is established, preventing arbitrary tampering of the performance logic by a single administrator or malicious attacker. By introducing multi-party consensus verification, the system ensures that all updates to business rules (such as rates, limits, or access conditions) are public, transparent, and collectively confirmed. This not only eliminates execution disputes caused by inconsistent rule versions but also effectively guarantees the fairness and stability of the contract logic in long-term operation.

[0038] In some embodiments of this application, the compliance and risk control layer smart contract is also configured to perform a security verification operation: an unlock signal that allows the execution layer smart contract to execute is generated only when the digital signature in the verification credential passes the verification and the timestamp carried by the credential is within a preset valid time window; if the verification fails, the execution process is terminated and the abnormal status is recorded.

[0039] In this way, a robust defense against replay attacks and data forgery is constructed. By rigorously verifying digital signatures and time windows, the system can confirm that the acquired external state does indeed originate from a trusted source and is within its validity period, thereby preventing attackers from using expired or forged credentials to deceive contract execution and ensuring the absolute reliability of the performance trigger conditions.

[0040] In some embodiments of this application, the compliance and risk control layer smart contract is specifically configured to implement the following steps.

[0041] Step S110: Invoke the oracle module using the authenticated access credentials.

[0042] In step S110, a trusted communication channel is established between the on-chain contract and the off-chain data service. By mandating the use of authenticated access credentials, the system effectively prevents unauthorized malicious calls or forged requests, ensuring that only legitimate, compliant, and risk-control-layer smart contracts can initiate data queries. This not only guarantees the reasonable use of oracle resources but also establishes the legitimacy and authenticity of data acquisition requests from the source, laying a secure foundation for obtaining highly reliable external data in the future.

[0043] Step S120: Receive the query results returned by the trusted off-chain data source, which include timestamps and electronic verification identifiers.

[0044] In step S120, external state evidence with legal validity and technical verifiability is obtained. The establishment of timestamps ensures data freshness and prevents replay attacks, where attackers use expired data to deceive the contract. Electronic verification identifiers serve as digital fingerprints verifying the authenticity of the data source, enabling smart contracts to verify on-chain data tampering through cryptographic means. This mechanism transforms the dynamic state of the real world into structured, machine-readable, and trustworthy information on the blockchain, breaking down information silos within the blockchain.

[0045] Step S130: If the query results show that the transaction entity is in a restricted state or has abnormal behavior records, the execution layer smart contract process is immediately suspended, and a risk warning event containing the reason for suspension is generated.

[0046] In step S130, real-time risk circuit breaking and anomaly blocking are implemented during the performance process. This gives smart contracts the ability to self-censor before executing business logic, proactively intercepting illegal transactions based on external authoritative blacklists or risk control data, thereby avoiding asset losses or compliance risks. Simultaneously, it generates risk warning events containing specific reasons for suspension, providing clear feedback to users and leaving immutable log records for off-chain regulatory audits and troubleshooting, achieving a unified approach to risk control and process transparency.

[0047] In some embodiments of this application, a heterogeneous data cleaning adapter is deployed within the oracle module, and the heterogeneous data cleaning adapter is configured to implement the following steps.

[0048] Step S210: Identify the header information of the original response message returned by the trusted off-chain data source, determine its data encapsulation format, and realize intelligent perception and protocol adaptation of multi-source heterogeneous data.

[0049] In step S210, since data sources in the real world often employ different communication protocols and data formats, this step empowers the oracle module to "understand" data from different sources, enabling it to automatically identify the structural characteristics of the data and thus laying the foundation for subsequent unified processing. This mechanism effectively solves the interaction barriers between the blockchain and external systems caused by incompatible data formats, ensuring that the system can flexibly access various third-party data services without having to develop separate interfaces for each data source, greatly improving the system's scalability and compatibility.

[0050] Step S220: According to the data encapsulation format, the preset parsing operators stored in the configurable operator library of the oracle module are called to parse the original response message and extract key status fields in order to accurately extract the core elements required for performance decision from massive and redundant network transmission data.

[0051] In step S220, through targeted parsing operators, the system can filter out noise information unrelated to business logic, retaining only key variables such as user credit scores, device operating status, or regulatory identifiers. This process not only reduces the computational burden of on-chain contract data processing but also ensures the purity and relevance of input data, preventing redundant or erroneous information in the original messages from interfering with the smart contract's judgment logic, thereby improving the accuracy of performance control.

[0052] Step S230: Map the key state fields to a standardized data structure that conforms to the preset smart contract interface standard.

[0053] In step S230, the semantic differences between off-chain data and on-chain contracts are eliminated, achieving standardization and unification of data interaction. By converting data from different sources into a unified format that smart contracts can directly understand and process, this step shields the differences in underlying data sources. This allows compliance and risk control layer smart contracts to disregard the specific source format of the data and simply call it according to the standard interface. This standardized processing mechanism greatly reduces the development complexity and maintenance cost of smart contracts, while also providing a common language foundation for cross-system and cross-platform data interoperability.

[0054] Step S240: Digitally sign and encapsulate the standardized data structure to generate an external state verification credential.

[0055] In step S240, immutable cryptographic proof is assigned to off-chain data, establishing its trustworthy status in the on-chain environment. Through digital signature technology, the oracle module binds its own reputation to the authenticity of the data, enabling smart contracts to verify the signature upon receiving data to confirm that the data has not been tampered with during transmission and indeed originates from a trusted oracle node. This mechanism upgrades ordinary network data into a legally valid and secure verification credential, constructing a trust transfer chain from off-chain to on-chain, which is the cornerstone of ensuring the secure operation of the entire performance control system.

[0056] In some embodiments of this application, to achieve trusted data interaction between the compliance and risk control layer smart contract and the oracle module, this application defines a standardized on-chain interface data structure. Specifically, the ABI (Application Binary Interface) definition of the smart contract includes the following core structures and functions: First, define the `struct External Data Source` to encapsulate the metadata of the off-chain data source, including: `url` (data source address, string type), `required Format` (predefined data encapsulation format, enumeration type, such as JSON / XML), and `callback Function Id` (callback function identifier, bytes4). Second, define the `struct Verification Payload` to carry the verification payload returned by the oracle, including: `data` (key state field, bytes), `timestamp` (timestamp, uint256), `signature` (digital signature, bytes), and `oracle Node Id` (oracle node ID, address).

[0057] At the function level, the compliance and risk control layer smart contract initiates a request to the oracle network via the function `request Data From Oracle(bytes 32 jobId, External Data Source call data source)`, where the `jobId` specifies the specific task script that the oracle node needs to execute. After completing the off-chain computation, the oracle module calls back to the contract via the function `fulfill Data(bytes 32 request Id, Verification Payload call datapayload)`, where the `requestId` is bound to the initial request to ensure that the data is not obfuscated.

[0058] In some embodiments of this application, to address the issue of diverse off-chain data source formats (such as XML, JSON, HTML, etc.), this application deploys a heterogeneous data cleaning adapter within the oracle module. Its specific execution is based on a three-step algorithm flow: "protocol fingerprint recognition - rule extraction - schema mapping". Step 1: Protocol Fingerprint Identification and Regular Expression Matching. After receiving the raw response message, the adapter first parses the Content-Type field in the HTTP header to determine the underlying protocol type. Then, it loads a pre-configured regular expression library to perform a streaming scan of the message. For example, when a message containing... <status>When the tag is used, XML parsing rules are automatically triggered. <status> (.*?)< / status> Extract the raw status value; if it is identified as JSON, locate the key fields using a predefined JSON Path expression (such as $.data.status).

[0059] Step 2: Deep extraction based on DOM tree or JSON path. After initial identification, the adapter calls the pre-compiled parsing script. For XML format, the DOM parser is used to build the message into a document object model tree, and nodes are precisely located using XPath expressions (such as / / Response / Status); for complex nested JSON data, its key-value pair structure is recursively traversed.

[0060] Step 3: Standardized Mapping Based on a Predefined Schema. The extracted raw fields are transformed using the Schema Mapper component. This component maintains a pre-compiled mapping table, mapping heterogeneous raw values ​​to enumerated values ​​conforming to the smart contract interface standard. For example, the string "Active" or the number "1" from off-chain data is uniformly mapped to the Status Code.VALID (uint8:1) defined within the contract. Finally, using template-based serialization technology (such as Go Template), the cleaned data is forcibly encapsulated into binary data conforming to the Verification Payload structure. This mechanism ensures that the system does not require a service restart; only a configuration update is needed to adapt to new data source formats.

[0061] In some embodiments of this application, the structured execution log includes the following fields: participant identity, operation type, occurrence time, numerical information, verification result, external data source referenced and its verification identifier.

[0062] Therefore, the structured execution log constructs a comprehensive chain of evidence for the performance process, achieving a deep binding between business operations and verification basis. This transforms the log from a simple record of state changes into a complete contextual information including "who did what, when, based on what data, and what the result was." In particular, the introduction of external data sources and verification identifiers makes the reference of off-chain data traceable and verifiable, effectively solving the problem of "separation between on-chain behavior and off-chain evidence" in traditional blockchain auditing. This provides tamper-proof and semantically rich original credentials for subsequent compliance reviews, dispute arbitration, and cross-system data reconciliation.

[0063] In some embodiments of this application, the log generation module is also configured to support exporting structured execution logs as standardized data packets after authorization, so that external systems can read and compare them, breaking down data silos in the blockchain system and achieving seamless interoperability between on-chain audit data and off-chain regulatory or business systems.

[0064] Through standardized encapsulation, complex on-chain logs are transformed into a universal data format, enabling external auditing firms, regulatory bodies, or partner systems to directly parse and automatically process this data without manual intervention or the development of custom parsing tools. This mechanism significantly improves the efficiency of cross-institutional collaboration, reduces compliance costs, and allows blockchain-based performance records to truly integrate into the existing business and legal ecosystem, enhancing the system's practical value.

[0065] In some embodiments of this application, the log generation module is configured to: use an asymmetric encryption algorithm to encrypt and store sensitive numerical information in the structured execution log, generate a ciphertext log corresponding to the public key of the access requester, and build an absolute security barrier for on-chain data.

[0066] Specifically, by employing asymmetric encryption technology, the system can perform high-strength mathematical transformations on sensitive values ​​involving trade secrets or personal privacy at the source of log generation. This mechanism ensures that even though blockchain, as a distributed ledger, is publicly transparent, unauthorized third parties or malicious nodes accessing data stored on the chain will only see unreadable gibberish. Encryption using the public key of the requesting party guarantees, both physically and mathematically, that only the specific entity holding the corresponding private key has the possibility of data recovery. This achieves confidential storage and transmission of sensitive data in a public network environment without relying on a centralized trust institution, effectively preventing the risk of data leakage during storage and circulation.

[0067] In some embodiments of this application, the log generation module is further configured to: de-identify sensitive numerical information or return corresponding ciphertext logs according to the access requester's permission level. The ciphertext logs can be decrypted by the access requester at an off-chain terminal using a private key held locally to obtain plaintext.

[0068] Specifically, by introducing a permission level determination mechanism, the system can intelligently identify the identity attributes of visitors. For users with insufficient permissions, only anonymized data that has been blurred or masked is displayed, which satisfies basic auditing or viewing needs while strictly limiting the exposure of core sensitive information. For requesters with legitimate permissions, the system provides a complete encrypted log and mandates that they perform decryption operations on an off-chain terminal using a locally and strictly guarded private key. This design cleverly moves the decryption process off-chain, completely avoiding the risk of private key leakage during network transmission or smart contract execution, ensuring the non-repudiation of data decryption and terminal security, and truly achieving the refined management goal of data being usable but invisible and authorized access on demand.

[0069] In some embodiments of this application, log access permissions are divided into four levels: Level 1 is the ordinary participant level: only able to view the log hash value and final execution result of the transactions they participated in, with sensitive numerical information completely hidden; Level 2 is the auditing institution level: able to view the anonymized logs of all transactions, with sensitive numerical information replaced by range values ​​(e.g., "1 million to 5 million yuan"); Level 3 is the system administrator level: able to view the complete plaintext logs, but unable to modify the log content already uploaded to the blockchain; Level 4 is the regulatory agency level: possessing the highest access permissions, able to view all plaintext logs and export the full standardized data package. The permission level is bound to the blockchain account address of the accessing party, and permission changes require multi-node consensus from the rule governance module to take effect.

[0070] In some embodiments of this application, the rule governance module is configured to establish a dynamic rule weight model. The governance nodes are selected from at least one of regulatory agency nodes, core enterprise nodes, and arbitration institution nodes, constructing a multi-party co-governance ecosystem that takes into account the authority of administrative supervision, the efficiency of business operations, and the impartiality of legal arbitration. This breaks the centralized drawback of traditional smart contracts where the rule-making is dominated by a single developer, and quantifies and integrates the will of different stakeholders into the governance architecture through weights.

[0071] By introducing diverse governance entities, the system can ensure that rule updates not only conform to technical logic but also adapt to legal and regulatory constraints and changes in the business environment. This establishes a trust mechanism based on game balance in a decentralized network, effectively preventing systemic risks caused by single-point decision-making errors or malicious tampering, and enhancing the social credibility and ecological stability of the entire performance control system.

[0072] In some embodiments of this application, when a performance trigger request is received, the compliance and risk control layer smart contract is also configured to calculate the comprehensive risk score of the current transaction, specifically including: dynamically loading the corresponding verification strategy in the rule base according to the comprehensive risk score; and automatically increasing the threshold of the number of governance nodes required in the multi-node consensus verification when the comprehensive risk score exceeds a preset threshold.

[0073] Specifically, upon receiving a performance trigger request, the compliance and risk control layer smart contract calculates a comprehensive risk score and dynamically loads the corresponding verification strategy from the rule base. This achieves a leap from static defense to dynamic adaptation in the performance risk control mechanism, flexibly adjusting the control intensity based on the specific risk level of the current transaction, rather than applying a rigid "one-size-fits-all" approach to all transactions. For low-risk transactions, the system can load lightweight strategies to improve processing efficiency and user experience; for high-risk transactions, it automatically matches strict verification logic. This mechanism finds the optimal balance between ensuring fund security and maintaining efficient system operation, enabling smart contracts to handle complex and ever-changing business scenarios with ease, significantly reducing false positives and false negatives.

[0074] When the overall risk score exceeds a preset threshold, the system automatically increases the threshold for the number of governance nodes required for multi-node consensus verification, constructing a resilient security defense line positively correlated with the risk level. This deeply couples risk control with rule governance. When abnormal or high-risk behavior is detected, the system no longer relies on the judgment of a few nodes but forces a wider range of governance nodes to reach a consensus before executing critical operations. This mechanism significantly increases the difficulty and cost for attackers to tamper with rules or bypass risk control, as attackers must control more governance nodes simultaneously to achieve their malicious purposes. Through this strategy of dynamically raising the trust threshold, the system can automatically enter a "high-alert state" when facing potential threats, effectively curbing the impact of malicious transactions on system stability and ensuring the security of contract fulfillment in extreme situations.

[0075] The comprehensive risk score is generated through weighted summation based on the types of abnormal records and historical violation frequencies in the external state information returned by the oracle module. This provides objective, authentic, and timely real-world evidence for smart contract risk assessment. In this way, the historical behavior and current state of off-chain entities are directly mapped to quantitative risk indicators on-chain, solving the problem of "blind execution" caused by the lack of contextual information in blockchain systems. By introducing abnormal record types and violation frequencies as scoring dimensions, the system can accurately identify trading entities with poor credit records or potential fraudulent tendencies, thus creating a precise risk profile before performance occurs. This risk quantification mechanism based on empirical data extends the contract execution logic beyond code-level logic judgments to a deeper consideration of the creditworthiness of trading entities, greatly enhancing the system's anti-fraud capabilities and compliance.

[0076] In some embodiments of this application, for the dynamic rule weight model, firstly, a set of governance nodes is defined. Each node Have basic weight (For example, the weight of regulatory agencies is set to 3, core enterprises to 2, and arbitration institutions to 1). The minimum consensus threshold required for currently effective rule changes. Its initial value is set to .

[0077] Upon receiving a performance request, the compliance and risk control layer's smart contract calculates a comprehensive risk score. The score is based on the weight of the abnormal record type in the external state information. (For example, "dishonest judgment debtor" has a weight of 5, and "administrative penalty" has a weight of 3), compared with historical violation frequency. Generated using a weighted formula: ;in, , This is the normalization coefficient.

[0078] Subsequently, the system executes a dynamic weighting strategy: calculating the dynamic adjustment factor. ;in, The preset risk threshold; the final consensus verification threshold. Adjusted to: ;in, This represents the weight increment for each level.

[0079] In some embodiments of this application, an initial consensus verification threshold is given, and the calculated threshold is then used to verify the consensus verification threshold. Substitute into the piecewise function, for example: when When the value is less than 50, a low-risk strategy is maintained, requiring only one governance node signature to unlock; when the value is less than or equal to 50, the strategy is changed to a lower-risk strategy. When the threshold is less than 100, a medium-risk strategy is triggered, requiring the quorum selector function to be called to forcibly increase the minimum number of nodes required for consensus verification from 1 to 3 (i.e., requiring dual endorsement from regulatory agencies and core enterprises); when When the value is ≥100, the circuit breaker mechanism is triggered, automatically locking the execution process and forcibly requiring more than 5 governance nodes (including arbitration institution nodes) to intervene for manual review.

[0080] This interconnected relationship enables the elastic scaling of the system's security strategy: it is not a static configuration, but rather a dynamic reconfiguration of the blockchain network's consensus parameters (Quorum Threshold) based on real-time risk scores. Technically, this constructs an adaptive defense line where "the more dangerous the situation, the higher the threshold," effectively addressing the technical shortcomings of static smart contracts in handling dynamic business risks.

[0081] In some embodiments of this application, the multi-node consensus verification is implemented based on an improved PBFT (Practical Byzantine Fault Tolerance) algorithm. The specific consensus process includes the following steps: When the rule governance module receives a proposal transaction to update the rule base, the primary node first broadcasts the transaction, entering the pre-prepare phase, attaching the current view number V and sequence number N. Each replica node, upon receiving the message, verifies the transaction's legality and broadcasts a prepare message to other nodes. When a node collects 2f+1 prepare messages from different nodes (where f is the system's tolerable number of Byzantine nodes), it enters the commit phase and broadcasts a commit message. Only when nodes collect enough commit messages and all nodes agree on the hash value of the rule update transaction will the transaction be written into a block. At the data structure level, consensus message packets are serialized using Protocol Buffers format, containing message type, signature, timestamp, and payload data. This consensus mechanism based on message rotation and quorum verification ensures strong consistency and non-repudiation of rule base updates, representing a standard solution achievable in the blockchain technology field.

[0082] In some embodiments of this application, the execution layer smart contract is configured to interact with the compliance and risk control layer smart contract and the log generation module according to the following logic.

[0083] Step S310: After receiving the unlock signal sent by the smart contract of the compliance risk control layer, the preset performance transaction execution logic is triggered.

[0084] Step S310 establishes a strict "verify before execution" serial control mechanism to ensure the security of business operations. It places the execution-layer smart contract under the supervision of the compliance and risk control layer, ensuring that any basic performance operations, such as asset transfers or state changes, must be initiated only after external data verification and internal rule validation, and after obtaining explicit unlocking authorization. This mechanism effectively prevents unapproved transaction requests from directly entering the execution phase, preventing asset losses due to malicious attacks or violations, achieving refined control of execution permissions, and guaranteeing the compliance and certainty of contract execution.

[0085] Step S320: At each critical node of the execution of the fulfillment transaction, send the current business operation metadata to the log generation module.

[0086] Step S320 enables end-to-end visualization and real-time audit tracking of the performance process. By recording data at intermediate stages of execution, rather than just at the end, the system can fully reconstruct the transaction's lifecycle, including every parameter change, fund flow, and logical branch selection. This fine-grained recording method provides a precise chain of evidence down to the step level for potential disputes, allowing auditors or regulatory systems to trace the specific state of the transaction at any given moment. This significantly enhances system transparency and provides detailed data support for investigating logical errors or abnormal interruptions during execution.

[0087] Step S330: When the performance transaction is completed or terminated abnormally, send the execution result identifier to the log generation module to trigger the final on-chain evidence storage operation of the log.

[0088] In step S330, the final confirmation of rights and the solidification of immutable evidence are completed in the performance closure loop. Regardless of whether the transaction is successfully performed or abnormally terminated due to risk control interception or system error, this step ensures that the final state is permanently recorded on the blockchain, preventing data omissions or subsequent repudiation. By generating a clear result identifier, the system provides all participants with a definite proof of the transaction's final state. This not only marks the formal end of a round of interaction but also provides authoritative on-chain evidence for subsequent business reconciliation, financial settlement, and state synchronization of off-chain systems, ensuring the consistency and integrity of the distributed ledger state.

[0089] In some embodiments of this application, in order to ensure that the logs stored on the blockchain are both secure and controllable, the embodiments of this application detail the key management and encryption / decryption process based on asymmetric encryption.

[0090] The system employs a hybrid encryption mechanism. After generating the structured execution log, the log generation module first generates a random symmetric key. (For example, an AES-256 key), use this key to encrypt sensitive numerical information (such as transaction amounts or personal identification information) to generate ciphertext. Subsequently, the system retrieves the set of asymmetric public keys of the authorizing party from the access control list. Use each public key to encrypt the symmetric key. Generate envelope data The final data structure stored on the blockchain is as follows: .

[0091] In the decryption and demonstration phase of step S330, when a read request with the digital signature of the requester is received, the off-chain gateway node or the blockchain virtual machine with computing power first verifies the requester's permission level.

[0092] If the permission verification passes, the system retrieves the encrypted envelope corresponding to the requester. Use the requester's private key Decrypt and restore the symmetric key reuse Decrypting the ciphertext Display in plain text.

[0093] If permissions are insufficient, either encrypted data or de-identified pseudo-data processed by hashing will be returned directly.

[0094] This mechanism avoids storing plaintext private keys directly on the blockchain, thus solving the performance bottleneck of asymmetric encryption in handling large amounts of data.

[0095] Secondly, refer to Figure 2 This application provides a blockchain-based smart contract performance control method, applied to blockchain network nodes, which includes the following steps.

[0096] Step S100: Before triggering the fulfillment operation, generate a pre-verified transaction containing an oracle callback identifier and call the oracle module to access the off-chain trusted data source.

[0097] In step S100, a pre-liability triggering mechanism based on external facts is established, breaking the closed nature of smart contracts that can only rely on on-chain data. By introducing oracle callback identifiers, the system can clearly distinguish between ordinary transactions and special transactions that require external data verification, thereby accurately activating the data acquisition process. This step transforms objective states in the real world (such as weather data, exchange rate fluctuations, user identity authentication results, etc.) into triggering conditions that can be recognized by on-chain contracts, ensuring that the initiation of performance is not based on blind code execution, but on real and credible external events. This fundamentally solves the problem of information asymmetry between the blockchain and the real world, providing a solid data foundation for subsequent compliance verification.

[0098] Step S200: Receive the verification payload containing digital signature and timestamp returned by the oracle module.

[0099] In step S200, an external data credential with cryptographic security and timeliness proof is obtained. The digital signature, acting as a digital fingerprint of the data's authenticity, ensures that the payload has not been tampered with during transmission and truly originates from a trusted oracle node, preventing man-in-the-middle attacks or data forgery. The timestamp, on the other hand, provides a clear time dimension to the data, defining its freshness and validity window. This mechanism upgrades ordinary network data into legally valid and technically verifiable evidence, enabling smart contracts to securely process information from trusted sources in an untrusted network environment, providing the necessary input elements for building a high-security performance control system.

[0100] Step S300: Perform a security verification operation: verify the validity of the digital signature and the timeliness of the timestamp. If successful, generate a transaction unlock signal and proceed to the fulfillment execution process. If the verification fails, terminate the execution process and record the abnormal status.

[0101] In step S300, a robust dynamic security firewall is constructed to proactively defend against replay attacks and data expiration risks. By rigorously comparing signatures and time windows, the system can accurately identify and block malicious replay attacks that utilize historically valid data, ensuring that each fulfillment trigger is based on the latest state at the current moment. If verification fails, the system immediately terminates and records the anomaly. This not only blocks potentially risky transactions but also leaves traceable attack evidence for the system, reflecting the security principles of a zero-trust architecture and greatly enhancing the robustness and self-healing capabilities of smart contracts in the face of complex network threats.

[0102] Step S400: During execution, a structured execution log containing external data verification identifiers is generated and stored on the blockchain.

[0103] In step S400, a transparent evidence system that is traceable and auditable across the entire chain is constructed. By deeply binding external data verification identifiers with internal execution operation records, the system achieves a logical closed loop between on-chain behavior and off-chain evidence, enabling any transaction to be traced back to the specific external environment and data source at the time of its triggering. This structured log recording method not only meets the stringent requirements of regulatory agencies for business compliance and data integrity, but also provides tamper-proof, judicial-grade evidence for potential commercial disputes, effectively resolving the trust crisis caused by black-box execution in traditional blockchain applications and enhancing the system's credibility.

[0104] Step S500: When it is necessary to update the performance judgment rules, initiate a multi-node consensus process, and update the rule base version after verification and confirmation by multiple preset governance nodes.

[0105] Step S500 establishes rule governance sovereignty in a decentralized environment, preventing arbitrary alteration of contract logic and abuse of power by a single entity. By introducing a multi-party consensus mechanism, rule changes are no longer decided unilaterally by developers or administrators, but must be collectively endorsed by governance nodes such as regulatory agencies, core partners, or community representatives. This mechanism ensures that the evolution of performance rules is open, transparent, and in line with the interests of all parties, effectively eliminating participants' concerns about opaque operations and laying the institutional foundation for building a long-term, stable, fair, and trustworthy blockchain business ecosystem.

[0106] In some embodiments of this application, when the oracle module call times out, returns no result, or returns an invalid message, the compliance and risk control layer smart contract triggers a retry mechanism by default. The retry interval is 10 seconds, and the maximum number of retries is 3. If no valid response is obtained after 3 retries, it is determined that the external data acquisition has failed, the current fulfillment process is automatically terminated, an abnormal status record of "external data source unavailable" is generated, and a prompt message is returned to the transaction initiator. For high-priority transactions, a "downgrade strategy after data acquisition failure" can be configured in the rule base, such as switching to an alternative data source for querying, or temporarily increasing the transaction risk level to load stricter local verification rules, to avoid affecting the operation of core businesses due to external data source failures.

[0107] In some embodiments of this application, taking the application scenario of automatic payment of accounts receivable between core enterprises and upstream suppliers as an example, the system is deployed on a consortium blockchain network. The governance nodes include three types of entities: local banking and insurance regulatory bureau nodes, core enterprise group nodes, and local commercial arbitration committee nodes. The rule base presets the basic rule of "automatic payment of accounts receivable on the due date", and stipulates that the payment trigger condition is "accounts receivable are due and the creditor has no record of being a dishonest person subject to enforcement". The initial consensus threshold is set to 3.

[0108] When the accounts receivable due date triggers a performance request, the compliance and risk control layer smart contract first uses access credentials certified by the core enterprise to call the oracle module, access the Supreme People's Court's public query interface for the list of dishonest judgment debtors, the heterogeneous data cleaning adapter of the oracle module recognizes that the returned message is in JSON format, calls the preset JSON Path operator to extract the "dishonest status" field of the supplier entity, maps it to the contract standard enumeration value, and generates a verification credential with a digital signature of the data source and the current timestamp, which is then returned to the chain.

[0109] The compliance and risk control layer smart contract verifies the signature validity and the timestamp is within the 5-minute validity window. After confirming that the supplier has no record of dishonesty, a comprehensive risk score of 28 is generated (below the 50-point threshold). An unlock signal is generated and sent to the execution layer smart contract. The execution layer automatically triggers a cross-account transfer operation for the 1.28 million yuan payment. During the process, the log generation module synchronously records a structured log containing the participant's DID identifier, operation type "payment execution", occurrence timestamp, amount hash, verification result "passed", dishonesty query data source URL and voucher ID. Sensitive amount fields are encrypted using AES-256 and then stored on the blockchain. Only the supplier, core enterprise, and regulatory node are granted corresponding decryption permissions.

[0110] In some embodiments of this application, taking the automatic payment of customs duties for cross-border e-commerce goods on the China-Europe Railway Express as an example, the off-chain trusted data source is connected to the customs duty inquiry system of the General Administration of Customs of the destination country and the international logistics tracking platform. The governance nodes include customs supervision nodes, cross-border e-commerce platform nodes, and logistics enterprise nodes. The rule base is preset with the rule "automatically deducting the corresponding customs duties from the enterprise's deposit account after the goods arrive at the port", and the effective time window is configured as 24 hours.

[0111] When the logistics system pushes cargo arrival information, the system triggers a fulfillment request. The oracle module simultaneously accesses the customs tariff query interface and the logistics tracking platform. The heterogeneous data cleaning adapter processes the XML-formatted tariff declaration message returned by customs and the CSV-formatted tracking data returned by the logistics platform, extracting two key fields: the actual tariff amount of €24,700 and the cargo arrival indicator. These are then mapped to a unified contract standard structure to generate a verification certificate. The compliance and risk control layer smart contract verifies that the signatures of both data sources are valid and the timestamps are within a 24-hour window. A comprehensive risk score of 62 (between 50 and 100 points) is calculated, automatically triggering a medium-risk strategy and raising the consensus verification threshold to 4. After consensus is reached among customs, the e-commerce platform, the logistics company, and the arbitration node, the execution layer smart contract is unlocked to complete the tariff deduction. If the tariff amount returned by the oracle deviates from the preset order tariff by more than 10%, the comprehensive risk score automatically rises to 112 (exceeding the 100-point threshold), triggering a circuit breaker mechanism, terminating the automatic execution process, generating a risk warning event, and pushing it to customs personnel for manual review.

[0112] Furthermore, embodiments of this application provide an electronic device, including one or more processors and a storage device. The storage device is used to store one or more programs; when one or more programs are executed by one or more processors, the one or more processors implement the aforementioned blockchain-based smart contract performance control method.

[0113] Furthermore, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the aforementioned blockchain-based smart contract performance control method.

[0114] In summary, the blockchain-based smart contract performance control system, method, device, and medium provided in this application have the following technical effects.

[0115] This solution constructs a performance execution mechanism that integrates off-chain trusted data verification, dynamic risk control, refined log traceability, and multi-party collaborative governance. It effectively addresses the security risks and trust issues caused by data silos, rigid risk control, and auditing difficulties inherent in traditional smart contracts. The system not only achieves closed-loop management of the entire performance process from pre-verification and in-process execution to post-event traceability, but also ensures the transparency and auditability of business operations by introducing external data source verification identifiers and structured logs. Furthermore, by leveraging a dynamic rule weight model and multi-node consensus governance, it enhances the adaptability and resilience of contract rules to complex business environments. Ultimately, while protecting user privacy and business secrets, it significantly reduces performance dispute rates and manual intervention costs, providing an efficient, secure, and compliant trusted execution environment for high-value scenarios such as financial transactions and supply chain collaboration.

[0116] It should be noted that in all specific embodiments of this application, all data processing activities related to user identity or personal characteristics, such as user information, user behavior data, historical data, and location information, will be conducted in accordance with the principles of legality, legitimacy, and necessity. All data collection, use, storage, and processing will be subject to compliance with applicable national and regional laws, regulations, and industry standards, and informed consent from users will be obtained in a clear and explicit manner before processing. For the processing of sensitive personal information, separate consent from users will be obtained through prominent means such as pop-up prompts and independent confirmation pages. If any processing conflicts with laws and regulations, the laws and regulations will prevail, and necessary data processing will only be carried out within the scope permitted by laws and regulations, ensuring that all data-based applications, analyses, and technical implementations are conducted within the scope permitted by laws and regulations.

[0117] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0118] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of ordinary skill of an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary skill. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0119] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several programs to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0120] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequential list of executable programs for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, a program execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can retrieve and execute a program from or in conjunction with such a program execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit a program for use by or in conjunction with a program execution system, apparatus, or device.

[0121] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Additionally, computer-readable media can even be paper or other suitable media on which programs can be printed, for example, by optically scanning the paper or other media, then editing, interpreting, or, if necessary, processing it in a suitable manner to obtain the program electronically, and then storing it in computer memory.

[0122] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable program execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0123] In the foregoing description of this specification, references to terms such as "one embodiment / implementation," "another embodiment / implementation," or "certain embodiments / implementations," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in an embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0124] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0125] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.< / status>

Claims

1. A blockchain-based smart contract performance control system, deployed in the contract execution environment of a blockchain node, comprising an execution layer smart contract configured to perform basic performance operations, a compliance and risk control layer smart contract, an oracle module, a log generation module, and a rule governance module: The compliance and risk control layer smart contract is configured to call the oracle module to access the off-chain trusted data source before triggering the performance operation, so as to obtain the external state verification certificate of the transaction subject, and decide whether to unlock the execution process based on the verification result of the verification certificate. The log generation module is configured to generate a structured execution log containing business operation metadata and the associated identifier of the external status verification certificate during the performance operation, and store the structured execution log in the blockchain in encrypted form. The rule governance module is configured to maintain a rule base for judging performance conditions. Updates to the rule base require multi-node consensus verification by multiple preset governance nodes before they can take effect. in, The compliance and risk control layer smart contract is also configured to perform a security verification operation: only when the digital signature in the verification credential passes the verification and the timestamp carried by the credential is within a preset valid time window will an unlock signal be generated to allow the execution layer smart contract to execute. If the verification fails, terminate the execution process and record the abnormal status.

2. The blockchain-based smart contract performance control system according to claim 1, wherein the smart contract of the compliance and risk control layer is specifically configured as follows: Invoke the oracle module using authenticated access credentials; Receive the query results containing timestamps and electronic verification identifiers returned by the off-chain trusted data source; If the query results show that the transaction entity is in a restricted state or has abnormal behavior records, the process of the execution layer smart contract will be immediately suspended, and a risk warning event containing the reason for suspension will be generated.

3. The blockchain-based smart contract fulfillment control system according to claim 2, wherein a heterogeneous data cleaning adapter is deployed within the oracle module; The heterogeneous data cleaning adapter is configured as follows: Identify the header information of the original response message returned by the trusted off-chain data source and determine its data encapsulation format; Based on the data encapsulation format, the preset parsing operators stored in the configurable operator library of the oracle module are invoked to parse the original response message and extract key status fields; The key status fields are mapped to standardized data structures that conform to the preset smart contract interface standards; The standardized data structure is digitally signed and encapsulated to generate the external state verification credential.

4. The blockchain-based smart contract performance control system according to claim 1, wherein the structured execution log includes the following fields: participant identity identifier, operation type, occurrence time, numerical information, verification result, external data source referenced and its verification identifier; The log generation module is also configured to support exporting the structured execution log into a standardized data packet after authorization, so that external systems can read and compare it.

5. The blockchain-based smart contract performance control system according to claim 4, wherein the log generation module is configured to use an asymmetric encryption algorithm to encrypt and store sensitive numerical information in the structured execution log, and generate a ciphertext log corresponding to the public key of the access requester; The log generation module is also configured to de-identify the sensitive numerical information or return the corresponding encrypted log according to the access requester's permission level. The encrypted log can be decrypted by the access requester using a private key held locally on an off-chain terminal to obtain the plaintext.

6. The blockchain-based smart contract performance control system according to claim 1, wherein the rule governance module is configured to establish a dynamic rule weight model; the governance node is selected from at least one of regulatory agency nodes, core enterprise nodes, and arbitration institution nodes; Upon receiving a performance trigger request, the compliance and risk control layer smart contract is also configured to calculate a comprehensive risk score for the current transaction; in, The comprehensive risk score is generated by weighted summation based on the weights of abnormal record types and historical violation frequencies in the external state information returned by the oracle module. Based on the comprehensive risk score, the corresponding verification strategy in the rule base is dynamically loaded; When the comprehensive risk score exceeds a preset threshold, the threshold for the number of governance nodes required in the multi-node consensus verification is automatically increased.

7. The blockchain-based smart contract performance control system according to claim 1, wherein the execution layer smart contract is configured to interact with the compliance and risk control layer smart contract and the log generation module according to the following logic: Upon receiving the unlock signal sent by the smart contract of the compliance and risk control layer, the preset performance transaction execution logic is triggered; At each critical node in the execution of the fulfillment transaction, send the current business operation metadata to the log generation module; When a transaction is completed or terminated abnormally, an execution result identifier is sent to the log generation module to trigger the final on-chain evidence storage operation of the log.

8. A blockchain-based smart contract performance control method, applied to blockchain network nodes, the method comprising: Before triggering the fulfillment operation, a pre-verified transaction containing an oracle callback identifier is generated, and the oracle module is invoked to access the off-chain trusted data source; Receive the verification payload containing digital signature and timestamp returned by the oracle module; Perform a security verification operation to check the validity of the digital signature and the timeliness of the timestamp. If the verification passes, a transaction unlock signal is generated and the performance execution process begins. If the verification fails, the execution process is terminated and the abnormal status is recorded. During execution, a structured execution log containing external data verification identifiers is generated and stored on the blockchain; When it is necessary to update the performance judgment rules, a multi-node consensus process is initiated, and the rule base version is updated after verification and confirmation by multiple preset governance nodes.

9. An electronic device, comprising: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the blockchain-based smart contract performance control method as described in claim 8.

10. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the blockchain-based smart contract performance control method as described in claim 8.

Images