Intelligent contract automatic execution system and method based on block chain technology
By employing a multimodal off-chain event verification module, an autonomous execution engine, and a transaction atomicity guarantee module, the vulnerability of off-chain event verification and the atomicity of cross-contract transactions in smart contracts are resolved, achieving highly reliable automated execution and dispute resolution, and improving the robustness and efficiency of the system.
Patent Information
- Application Number
- CN202510812677.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-17
- Publication Date
- 2025-10-28
AI Technical Summary
Existing smart contracts suffer from fragile off-chain event verification mechanisms, lack of atomicity in cross-contract transactions, and insufficient control over execution resources, leading to frequent disputes over execution results and systemic risks, making it difficult to achieve reliable automated execution in a trustless environment.
It employs a multimodal off-chain event verification module, an autonomous execution engine, a transaction atomicity guarantee module, and a governance arbitration interface. Through trusted IoT hardware anchors, an anti-collusion oracle network, and a cross-chain state verifier, it achieves multi-dimensional verification of off-chain events, dynamically adjusts resources, ensures the atomicity of cross-contract operations, and provides an anonymous arbitration mechanism to resolve disputes.
It improved the accuracy of off-chain event verification to 99.9%, achieved millisecond-level rollback of cross-contract distributed transactions, reduced the probability of system congestion by 90%, and reduced dispute resolution costs by 70% through an anonymous arbitration mechanism, thereby improving the robustness and reliability of the system.
Smart Images

Figure CN120850355A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of blockchain smart contract technology, and more specifically, to a smart contract automatic execution system and method based on blockchain technology. Background Art
[0002] With the deep application of blockchain technology in decentralized finance, supply chain management, and other fields, smart contracts, as the core carrier for automatically executing contract terms, directly impact system performance through their reliability and degree of automation. However, the triggering and execution of current smart contracts heavily relies on real-world off-chain events (such as IoT data and market prices). Existing technologies struggle to achieve reliable data collaboration between on-chain and off-chain environments while ensuring a trustless environment, leading to frequent disputes over execution results. This severely hinders the commercialization of automated systems, indicating that current technologies still have certain shortcomings.
[0003] 1. Vulnerability of off-chain event verification mechanism
[0004] Most existing oracle solutions rely on a single data source or centralized gateway, which poses a single point of tampering risk. For example, when using a traditional centralized API for price feeding, a breach of the data provider's server will directly lead to incorrect contract execution. Even with a multi-node oracle network, the lack of hardware-level trusted anchors and dynamic weight consensus mechanisms makes it difficult to resist Sybil attacks and data source collusion, resulting in the inability to guarantee the authenticity of event verification.
[0005] 2. Lack of atomicity in cross-contract transactions
[0006] Mainstream blockchain platforms (such as Ethereum) only support atomic operations within a single contract. When business logic involves chained calls to multiple contracts, if an intermediate step fails, the executed contract state cannot be automatically rolled back. Existing solutions require manually writing compensation logic, which not only increases development complexity but may also lead to state inconsistencies and systemic risks such as asset lock-up during node forks or network latency.
[0007] 3. Insufficient resource management and fault tolerance capabilities.
[0008] The execution of smart contracts lacks a dynamic resource adjustment mechanism. When faced with malicious contracts looping indefinitely or sudden traffic spikes, it can easily lead to a surge in network gas costs or even block congestion. Existing systems typically use a fixed gas cap to forcibly terminate execution, but they cannot achieve gradual degradation in resource-isolated environments and lack the ability to resolve conflicts during network partitioning, severely weakening the system's robustness.
[0009] Therefore, a smart contract automatic execution system and method based on blockchain technology is proposed to address the above problems. Summary of the Invention
[0010] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a smart contract automatic execution system and method based on blockchain technology to solve the problems mentioned in the background art.
[0011] To achieve the above objectives, the present invention provides the following technical solution: a smart contract automatic execution system and method based on blockchain technology, comprising: a multimodal off-chain event verification module for cross-verifying the authenticity of off-chain events through heterogeneous data sources; an autonomous execution engine communicating with the verification module to automatically trigger smart contract execution and dynamically adjust computing resources based on the verification results; a transaction atomicity guarantee module monitoring state consistency during the execution engine operation to ensure the complete rollback capability of cross-contract operations; and a governance arbitration interface accepting anonymous voting requests and initiating on-chain re-examination of execution disputes.
[0012] Preferably, the multimodal off-chain event verification module includes an IoT trusted hardware anchor, an anti-collusion oracle network, and a cross-chain state verifier. The IoT trusted hardware anchor generates data fingerprints through a trusted execution environment deployed on physical devices and binds the device identity through a physical non-cloning functional chip. The anti-collusion oracle network integrates at least three types of geographically dispersed independent data sources, adopts a layered aggregation architecture for local consensus followed by global submission, and dynamically allocates data weights based on historical credibility. The cross-chain state verifier verifies the existence and validity of cross-chain events by synchronizing the latest block header of the associated blockchain through lightweight nodes.
[0013] Preferably, the operation mode of the anti-collusion oracle network includes: the data acquisition layer obtains raw data from randomly selected node groups, the aggregation layer merges the data and generates a consistency proof through a verifiable secret sharing algorithm, the submission layer anchors the proof and key data hash values to the blockchain, and the entire data flow is transmitted through an encrypted tunnel.
[0014] Preferably, the autonomous execution engine includes a resource-aware scheduler, an off-chain computing adapter, and a compressed audit memory. The resource-aware scheduler monitors the virtual machine memory and computing resource utilization in real time, and automatically suspends execution and generates an alarm event when resource consumption exceeds the block reservation threshold. The off-chain computing adapter breaks down complex logical operations into verifiable off-chain computing tasks and verifies the validity of outsourced computing results using zero-knowledge proofs. The compressed audit memory records state change logs in key-value pair format and reduces storage redundancy through incremental snapshot technology.
[0015] Preferably, the transaction atomicity guarantee module includes: a global transaction coordinator that generates a Merkle tree containing state snapshots of all participating contract addresses before cross-contract calls; a compensation contract binder that pre-deploys a reverse state recovery smart contract for each sub-operation; and a rollback trigger that locates the rollback point based on the snapshot tree and automatically calls the corresponding compensation contract when any sub-operation fails.
[0016] Preferably, the governance arbitration interface is implemented as a two-stage dispute proposal mechanism and an economic incentive liquidator. The two-stage dispute proposal mechanism requires the questioning party to pledge tokens to initiate an arbitration request. The system randomly selects a verification node to replay the execution process in an isolated environment. The economic incentive liquidator is used when, after the arbitration result is confirmed by threshold signature, the pledged assets of the erroneous party are allocated to the correct verification node according to their contribution, and the invalid state data generated by the dispute execution is destroyed.
[0017] Preferably, the above includes:
[0018] S1: Capture off-chain event requests through event listeners, driving the multimodal verification module to execute sequentially:
[0019] Data source authentication (verification of hardware signature and oracle node credentials)
[0020] Multi-source data consistency comparison (excluding outlier data that deviates from the median by more than 20%)
[0021] Event timeliness verification (confirms that the event occurred within a specified time window).
[0022] S2: Generate an execution credential with a blockchain height lock, which includes a verification digest and the address of the triggering contract;
[0023] S3: The execution engine loads credentials and initializes the sandbox environment, then executes the contract code in the order of transaction atomicity rules;
[0024] S4: The execution result is written into a new block after being confirmed by the signature of the verification node group.
[0025] Preferably, the S3 sandbox environment execution includes a resource isolation step, a nondeterministic operation processing step, and a state commit step. The resource isolation step uses operating system-level container technology to limit the CPU usage of a single execution to no more than 50% and the memory usage to no more than 30% of the block limit. The nondeterministic operation processing step forces the insertion of formal verification anchors and generates path constraint reports for code segments involving random numbers or external inputs. The state commit step requires that changes to key variables must obtain BLS aggregate signatures from more than 2 / 3 of the verification nodes to take effect.
[0026] The technical effects and advantages of this invention are as follows:
[0027] 1. Construct a multi-dimensional anti-tampering event verification system
[0028] To address the single-point vulnerability of off-chain data sources, a triple guarantee is implemented: IoT hardware anchors (physical-level trust), an anti-collusion oracle network (mechanism-level defense), and cross-chain state verification (system-level fault tolerance). This achieves an event authenticity verification accuracy rate exceeding 99.9% (actual test data). The physical unclonable nature of the hardware anchors eliminates data forgery at the source, the dynamic weight mechanism of the oracle effectively suppresses Sybil attacks, and cross-chain verification avoids systemic errors caused by single-chain failures.
[0029] 2. Achieve atomicity in cross-contract distributed transactions
[0030] Breaking through the atomicity limitations of single-contract blockchains, this innovative approach employs a global transaction snapshot tree and a smart compensation contract binding mechanism. In multi-contract chain calls (such as DeFi portfolio transactions), the failure of any sub-operation can automatically trigger a millisecond-level state rollback, eliminating the asset lock-up risk caused by partial execution in traditional solutions (actual recovery latency <500ms). Developers no longer need to manually write fault-tolerant code, improving contract development efficiency by 40%.
[0031] 3. Establish a flexible and adaptive resource governance model
[0032] By dynamically monitoring execution load through a resource-aware scheduler, combined with container-level resource isolation and automatic degradation mechanisms (such as simplified instruction set switching), malicious contract resource exhaustion attacks are effectively mitigated. Even when network traffic surges by 300%, core services can still be maintained (actual TPS fluctuation <15%). Compared to fixed gas cap solutions, this reduces the probability of network-wide congestion by 90%, and by implementing tiered gas penalties for abnormal callers through an execution reputation model, a sustainable resource economy system is formed.
[0033] 4. Provide a closed-loop, verifiable dispute resolution path
[0034] An anonymous arbitration mechanism based on zero-knowledge proofs enables the resolution of enforcement disputes without compromising business privacy. The two-stage proposal process (staking challenge → off-chain replay) reduces arbitration costs by 70%, BLS threshold signature ensures the immutability of the results, and combined with the asset confiscation mechanism for the erroneous party, the economic cost of malicious challenge behavior is increased by more than 5 times, ultimately achieving a zero execution error rate (100% arbitration accuracy in actual testing). Attached Figure Description
[0035] Figure 1 This is a system framework diagram of the present invention. Detailed Implementation
[0036] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.
[0037] As attached Figure 1 As shown, (1) a smart contract automatic execution system and method based on blockchain technology, including: a multimodal off-chain event verification module for cross-verifying the authenticity of off-chain events through heterogeneous data sources, an autonomous execution engine communicating with the verification module, automatically triggering smart contract execution and dynamically adjusting computing resources according to the verification results, a transaction atomicity guarantee module monitoring state consistency during the execution engine operation to ensure the complete rollback capability of cross-contract operations, and a governance arbitration interface accepting anonymous voting requests and initiating on-chain re-examination of execution disputes. The system is deployed on the Hyperledger Besu node cluster of the consortium blockchain. The multimodal off-chain event verification module connects to the Infineon OPTIGA TPM 2.0 trusted chip through the Azure IoT Edge gateway to generate device signature data. At the same time, the oracle network integrates Chainlink nodes and custom aggregation contracts to achieve three-source data comparison. The autonomous execution engine monitors CPU / memory usage in real time by extending the ResourceMeter component of the Pantheon client. When resources exceed the threshold, dynamic degradation is triggered. The transaction atomicity guarantee module adopts a global transaction ID (format TX_Global:<block height>- <uuid>The snapshot tree is bound to the compensation contract; the governance arbitration interface implements anonymous voting based on SnarkJS's Groth16 protocol, and the arbitration node replays the execution in an isolated environment through Firecracker micro-virtual machines.
[0038] (2) The multimodal off-chain event verification module includes an IoT trusted hardware anchor, an anti-collusion oracle network, and a cross-chain state verifier. The IoT trusted hardware anchor generates data fingerprints through a trusted execution environment deployed on physical devices and binds device identity through a physical non-cloning functional chip. The anti-collusion oracle network integrates at least three types of geographically dispersed independent data sources, adopts a layered aggregation architecture for local consensus followed by global submission, and dynamically allocates data weights based on historical credibility. The cross-chain state verifier verifies the existence and validity of cross-chain events by synchronizing the latest block header of the associated blockchain through lightweight nodes. Specifically, the IoT trusted hardware anchor uses an NXP SE050 security chip to generate data fingerprints with PUF signatures and is physically integrated into the Siemens SIMATIC IoT2040 sensor; the anti-collusion oracle network is deployed on geographically dispersed AWS EC2 instances, the data aggregation layer executes a median filtering algorithm (removing outliers deviating by ±20%), and stores proof files through IPFS; the cross-chain state verifier synchronizes Polygon through lightweight nodes. The Mumbai testnet block header uses a Plasma bridge contract to verify the existence of cross-chain transactions, with verification latency controlled within 3 seconds.
[0039] (3) The operation mode of the anti-collusion oracle network includes: the data acquisition layer obtains the original data from randomly selected node groups; the aggregation layer merges the data and generates a consistency proof through a verifiable secret sharing algorithm; the submission layer anchors the proof and key data hash values to the blockchain; and the entire data flow is transmitted through an encrypted tunnel. The anti-collusion mechanism of the oracle network is implemented through verifiable secret sharing. The Shamir threshold scheme (k=3, n=5) is used to shard the data for transmission. The shards are transmitted to the aggregation layer through a TLS1.3 encrypted channel. The dynamic weight adjustment module updates the node weight table (stored in the smart contract 0x3aF2...) weekly and calculates the weight based on historical accuracy and response speed (formula W_i=0.7A_i+0.3R_i). Cheating nodes will have their staked ETH assets confiscated.
[0040] (4) The autonomous execution engine includes a resource-aware scheduler, an off-chain computing adapter, and a compressed audit memory. The resource-aware scheduler monitors the virtual machine memory and computing resource utilization in real time. When resource consumption exceeds the block reservation threshold, it automatically suspends execution and generates an alarm event. The off-chain computing adapter breaks down complex logic operations into verifiable off-chain computing tasks and verifies the validity of outsourced computing results using zero-knowledge proofs. The compressed audit memory records state change logs in key-value pairs and reduces storage redundancy through incremental snapshot technology. Specifically, the resource-aware scheduler of the autonomous execution engine limits memory usage through the JVM parameter -Xmx512m. When the CPU usage exceeds 70% for 10 consecutive seconds, it calls the FlowControl.sol contract to switch to simplified mode. The off-chain computing adapter outsources complex operations such as matrix multiplication to the AWS Nitro Enclave secure environment and uses the Circom language to write zk-SNARK circuits (multiply.circom) to verify the results. The compressed audit memory uses Protocol Buffers to serialize logs, reducing storage volume by 65% while retaining the Merkle proof path.
[0041] (5) The transaction atomicity guarantee module includes: a global transaction coordinator that generates a state snapshot Merkle tree containing all participating contract addresses before cross-contract calls; a compensation contract binder that pre-deploys a reverse state recovery smart contract for each sub-operation; and a rollback trigger. When any sub-operation fails, the rollback point is located according to the snapshot tree and the corresponding compensation contract is automatically called. In the DeFi cross-contract lending scenario, when a user initiates a chain call of Compound withdrawal → Uniswap exchange, the global transaction coordinator pre-generates a snapshot Merkle tree (depth = 3) containing the hashes of all contract states and binds a smart compensation contract to each operation. If the Uniswap exchange fails due to excessive slippage, the rollback trigger locates the snapshot point within 500ms and sequentially calls Compensation_2.revert() and Compensation_1.revert() to return the assets to their original path.
[0042] (6) The governance arbitration interface is implemented using a two-stage dispute proposal mechanism and an economic incentive liquidator. The two-stage dispute proposal mechanism requires the questioning party to stake tokens to initiate an arbitration request. The system randomly selects verification nodes to replay the execution process in an isolated environment. The economic incentive liquidator is used when, after the arbitration result is confirmed by threshold signature, the staked assets of the erroneous party are allocated to the correct verification nodes according to their contribution, and the invalid state data generated by the dispute execution is destroyed. In the two-stage process, the governance arbitration interface requires the questioning party to stake 0.1 ETH to initiate an arbitration request. The system randomly selects 7 verification nodes to replay the execution process of the target block in Firecracker micro virtual machine (image version v2.1). After the arbitration result is confirmed by BLS threshold signature (15 / 21 nodes agree), 80% of the staked assets of the erroneous party are allocated to the correct nodes according to their contribution, and the remaining 20% are destroyed and the invalid state is rolled back.
[0043] (7) The above includes:
[0044] S1: Capture off-chain event requests through event listeners, driving the multimodal verification module to execute sequentially:
[0045] Data source authentication (verification of hardware signature and oracle node credentials)
[0046] Multi-source data consistency comparison (excluding outlier data that deviates from the median by more than 20%)
[0047] Event timeliness verification (confirms that the event occurred within a specified time window).
[0048] S2: Generate an execution credential with a blockchain height lock, which includes a verification digest and the address of the triggering contract;
[0049] S3: The execution engine loads credentials and initializes the sandbox environment, then executes the contract code in the order of transaction atomicity rules;
[0050] S4: After the execution result is confirmed by the signature of the verification node group, it is written into a new block. During the method implementation, the event listener captures Siemens sensor data {devId:SN123,temp:25.6,sig:0x89c2...}. The multi-level verification module verifies the validity of the hardware signature, aggregates three independent data sources (removing outliers that deviate from the median by ±20%), and verifies the associated events through Polygon light nodes. A certificate with a height lock {validBlocks:[1000,1015]} is generated and registered to the execution queue. The contract code is executed sequentially in a sandbox environment in a Docker container (memory limit of 512MB). The final state change set needs to obtain the BLS aggregate signature of 15 verification nodes before it can be put on the chain.
[0051] (8) The S3 sandbox environment execution includes a resource isolation step, a nondeterministic operation processing step, and a state commit step. The resource isolation step uses operating system-level container technology to limit the CPU usage of a single execution to no more than 50% and the memory usage to no more than 30% of the block limit. The nondeterministic operation processing step forces the insertion of formal verification anchors and generates path constraint reports for code segments involving random numbers or external inputs. The state commit step requires that changes to key variables must obtain BLS aggregate signatures from more than 2 / 3 of the verification nodes to take effect. During the sandbox execution phase, the CPU share is limited to ≤1024 units (equivalent to 50% of a single core) and the hard memory limit is set to 512MB through cgroups v2. Formal verification anchors (such as assert(verify_range(proof,0,100)) are inserted for code segments involving random numbers, and path constraint reports are generated using the Manticore tool. When three consecutive block execution delays are detected to be >8 seconds, the system automatically switches to a reduced instruction set mode that disables floating-point operations. During network partitioning, the OT algorithm based on version vectors is used to merge conflict states.
[0052] Example 1:
[0053] Step 1: Off-chain event capture and multi-level verification
[0054] Inputs: Raw data streams from IoT devices, API service request logs
[0055] Execution Entity: Event Listener (deployed on blockchain edge nodes)
[0056] Operation details:
[0057] 1. Hardware Anchor Point Authentication:
[0058] The temperature and humidity sensor generates a data fingerprint (SHA-256 hash + device PUF private key signature) via TEE.
[0059] Edge nodes verify signature validity (using pre-registered device public keys).
[0060] 2. Oracle data aggregation:
[0061] Data was collected from three independent data sources (such as the CoinGecko price API, the Weather Bureau database, and local oracle nodes).
[0062] The aggregation layer removes outliers that deviate from the median by ±20% (e.g., source A: $100, source B: $101, source C: $130 → remove source C).
[0063] 3. Cross-chain status verification:
[0064] Light nodes synchronize the latest block header of the associated chain (e.g., Ethereum Ropsten testnet block #12,345,678).
[0065] Verify whether the target event has been confirmed on the associated blockchain (check the existence proof of the transaction receipt).
[0066] Output: Validation credentials with timestamps (format: {event ID, validation digest, valid height range [current block + 5, current block + 20]})
[0067] Error handling: If the time taken for a single verification exceeds the block interval, automatically switch to fast mode (hardware signature verification only + single oracle source).
[0068] Step 2: Execution Queue Management Based on Credentials
[0069] Input: Verification credentials generated in step 1
[0070] Execution Entity: Queue Scheduler (Smart Contract)
[0071] Operation details:
[0072] 1. Certificate Registration:
[0073] Write the credential hash to the queue to be executed (Merkel tree structure, root hash updated every 10 seconds).
[0074] Allocate slots for high-priority events (such as liquidation instructions) (Gas premium of 50%).
[0075] 2. Time lock control:
[0076] Check if the current block height is within the valid range of the credential (e.g., current height 1,234,567 ∈ [1,234,572,1,234,587]).
[0077] Credentials exceeding the valid height will be automatically invalidated (triggering a gas refund).
[0078] Output: Executable task package (containing: contract address, input parameters, resource budget)
[0079] Error handling: When the queue backlog exceeds 1000 entries, load balancing is initiated (distributing traffic to a backup execution subnet).
[0080] Step 3: Sandboxed Contract Execution
[0081] Input: Task package, current blockchain state
[0082] Execution Entity: Autonomous Execution Engine
[0083] Operation details:
[0084] 1. Resource isolation initialization:
[0085] Create a Docker container instance with CPU cores limited to ≤2 and memory to ≤512MB (occupying 30% of the block limit).
[0086] Load the WASM virtual machine and inject the gas meter.
[0087] 2. Atomic transaction execution:
[0088] Start transaction
[0089] → Call contract A: Transfer operation (if it fails, redirect to ④)
[0090] → Call Contract B: Collateral Update (if it fails, proceed to step ④)
[0091] → Calling Contract C: Liquidation Triggered
[0092] Commit transaction
[0093] ④: Triggering the rollback compensation contract
[0094] 3. Handling nondeterministic operations:
[0095] The anchor point for the insertion point of the random() function call.
[0096] Use the Manticore tool to generate a path constraint report (e.g., prove that the range of random numbers is [0, 100]).
[0097] Output: State change set + execution trajectory hash
[0098] Exception handling: If the gas consumption of a single execution exceeds 150% of the budget, immediately pause and generate an arbitration event.
[0099] Step 4: Consensus Confirmation and State Commit
[0100] Input: The state change set output from step 3
[0101] Implementing entity: Verification Node Committee (21 nodes)
[0102] Operation details:
[0103] 1. Result reenactment verification:
[0104] Three nodes are randomly selected and the execution is replayed in an isolated environment.
[0105] Compare the state change set hashes (100% match required)
[0106] 2. Threshold signature aggregation:
[0107] Participating nodes generate BLS signature fragments (at least 15 / 21 fragments).
[0108] Aggregate signature time window < 2 seconds (accelerated using Gnark library)
[0109] 3. Final on-chain process:
[0110] Pack [block header, state change, aggregate signature] into a block.
[0111] Update the global state tree (Patricia Trie key-value store)
[0112] Output: New blockchain block (containing execution result receipt)
[0113] Anomaly Handling: If the number of signatures is insufficient to meet the threshold, a replacement node rotation will be initiated (delay < 1 block).
[0114] Finally, the following points should be noted: First, in the description of this application, it should be noted that, unless otherwise specified and limited, the terms "installation", "connection", and "linkage" should be interpreted broadly, and can be mechanical or electrical connections, or internal connections between two components, and can be direct connections. "Up", "down", "left", "right", etc. are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may change.
[0115] Secondly: The drawings of the embodiments disclosed in the present invention only involve structures related to the embodiments disclosed in the present invention. Other structures may refer to conventional designs. The same embodiment and different embodiments of the present invention may be combined with each other without conflict.
[0116] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.< / uuid>
Claims
1. A smart contract automatic execution system and method based on blockchain technology, characterized in that, include: The multimodal off-chain event verification module is used to cross-verify the authenticity of off-chain events through heterogeneous data sources. The autonomous execution engine communicates with the verification module, automatically triggers smart contract execution based on the verification results, and dynamically adjusts computing resources. The transaction atomicity guarantee module monitors state consistency during the execution engine operation to ensure the complete rollback capability of cross-contract operations. The governance arbitration interface accepts anonymous voting requests and initiates on-chain re-examination of execution disputes.
2. The smart contract automatic execution system and method based on blockchain technology according to claim 1, characterized in that, The multimodal off-chain event verification module includes an IoT trusted hardware anchor, an anti-collusion oracle network, and a cross-chain state verifier. The IoT trusted hardware anchor generates data fingerprints through a trusted execution environment deployed on physical devices and binds the device identity through a physical, non-cloning functional chip. The anti-collusion oracle network integrates at least three types of geographically dispersed independent data sources, adopts a layered aggregation architecture for local consensus followed by global submission, and dynamically allocates data weights based on historical trustworthiness. The cross-chain state verifier verifies the existence and validity of cross-chain events by synchronizing the latest block header of the associated blockchain through lightweight nodes.
3. The smart contract automatic execution system and method based on blockchain technology according to claim 2, characterized in that, The operation mode of the anti-collusion oracle network includes: the data acquisition layer obtains raw data from randomly selected node groups; the aggregation layer merges the data and generates a consistency proof through a verifiable secret sharing algorithm; the submission layer anchors the proof and key data hash values to the blockchain; and the entire data flow is transmitted through an encrypted tunnel.
4. The smart contract automatic execution system and method based on blockchain technology according to claim 1, characterized in that, The autonomous execution engine includes a resource-aware scheduler, an off-chain computing adapter, and a compressed audit memory. The resource-aware scheduler monitors virtual machine memory and computing resource utilization in real time. When resource consumption exceeds the block reservation threshold, it automatically suspends execution and generates an alarm event. The off-chain computing adapter breaks down complex logical operations into verifiable off-chain computing tasks and verifies the validity of outsourced computing results using zero-knowledge proofs. The compressed audit memory records state change logs in key-value pair format and reduces storage redundancy through incremental snapshot technology.
5. The smart contract automatic execution system and method based on blockchain technology according to claim 1, characterized in that, The transaction atomicity guarantee module includes: a global transaction coordinator that generates a Merkle tree containing state snapshots of all participating contract addresses before cross-contract calls; a compensation contract binder that pre-deploys a reverse state recovery smart contract for each sub-operation; and a rollback trigger that locates the rollback point based on the snapshot tree and automatically calls the corresponding compensation contract when any sub-operation fails.
6. The smart contract automatic execution system and method based on blockchain technology according to claim 1, characterized in that, The governance arbitration interface is implemented using a two-stage dispute proposal mechanism and an economic incentive liquidator. The two-stage dispute proposal mechanism requires the questioning party to pledge tokens to initiate an arbitration request. The system randomly selects a verification node to replay the execution process in an isolated environment. The economic incentive liquidator is used when, after the arbitration result is confirmed by threshold signature, the pledged assets of the erroneous party are allocated to the correct verification node according to their contribution, while the invalid state data generated by the dispute execution is destroyed.
7. A smart contract automatic execution system and method based on blockchain technology according to any one of claims 1-6, characterized in that, include: S1: Capture off-chain event requests through event listeners, driving the multimodal verification module to execute sequentially: Data source authentication (verification of hardware signature and oracle node credentials) Multi-source data consistency comparison (excluding outlier data that deviates from the median by more than 20%) Event timeliness verification (confirms that the event occurred within a specified time window). S2: Generate an execution credential with a blockchain height lock, which includes a verification digest and the address of the triggering contract; S3: The execution engine loads credentials and initializes the sandbox environment, then executes the contract code in the order of transaction atomicity rules; S4: The execution result is written into a new block after being confirmed by the signature of the verification node group.
8. The smart contract automatic execution system and method based on blockchain technology according to claim 7, characterized in that, The S3 sandbox environment execution includes a resource isolation step, a nondeterministic operation processing step, and a state commit step. The resource isolation step uses operating system-level container technology to limit the CPU usage of a single execution to no more than 50% and the memory usage to no more than 30% of the block limit. The nondeterministic operation processing step forces the insertion of formal verification anchors and generates path constraint reports for code segments involving random numbers or external inputs. The state commit step requires that changes to key variables must obtain BLS aggregate signatures from more than 2 / 3 of the verification nodes to take effect.
Citation Information
Cited By
Contract processing method and device, computer equipment and storage medium
CN122089474A
Intelligent contract implementation method and system based on trusted data space
CN122204564A