Smart Contract Transaction Verification for Ledger Consistency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In blockchain networks, the frequent changes in data lead to inconsistencies in version numbers, resulting in a low success rate of writing transactions to the ledger, as endorsement nodes may access outdated data, causing transactions to be invalid and requiring re-initiation until version numbers are consistent.
Innovation Solution
The method involves processing nodes ignoring version numbers and data related to frequently modified restrictive conditions during verification, checking only those generated by other program conditions, and verifying local ledger data against the restrictive condition later, to increase the success rate of transaction writing.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If endorsement nodes check version numbers and data generated by restrictive conditions during verification, then data consistency is ensured, but transaction writing success rate decreases due to frequent data changes
Solution Approach 1:
The patent segments the verification process into two distinct parts: (1) verification of version numbers and data generated by non-restrictive program conditions, and (2) verification of restrictive conditions against local ledger data. This segmentation allows the system to maintain data consistency for critical restrictive conditions while avoiding rejection due to frequent changes in non-critical data, thereby resolving the contradiction between reliability and productivity.
Solution Approach 2:
The patent extracts the restrictive conditions from the complete set of program conditions and handles them separately. By identifying and isolating restrictive conditions (which represent critical business rules that must be satisfied), the system can verify only these essential conditions against local ledger data, rather than verifying all program conditions. This extraction reduces unnecessary verification overhead and increases transaction writing success rate while maintaining data consistency for critical conditions.
2Loss of time
If endorsement nodes access latest ledger data for smart contract execution, then data freshness is improved, but data inconsistency increases due to sequential synchronization delays
Solution Approach 1:
The patent applies local quality by allowing different types of data to be verified differently. For restrictive conditions, the system uses local ledger data stored at each processing node, which is updated sequentially and guaranteed to be consistent. For non-restrictive conditions, the system accepts data from endorsement nodes even if slightly outdated. This differentiated approach ensures data consistency for critical conditions while maintaining good data freshness overall.
Solution Approach 2:
The patent performs preliminary action by having endorsement nodes execute smart contracts and generate running results in advance, then submitting these results to processing nodes for verification. The processing nodes verify the results against their local ledger data before writing to the ledger. This preliminary execution allows endorsement nodes to use their locally cached data without causing inconsistency, as the final verification against local ledger data ensures consistency before commitment.
3Measurement precision
If all program conditions are verified during transaction validation, then verification accuracy is improved, but system performance decreases due to redundant checks
Solution Approach 1:
The patent extracts and identifies restrictive conditions from the complete set of program conditions through parsing the smart contract code. By separating restrictive conditions (critical business rules) from non-restrictive conditions, the system verifies only the essential restrictive conditions against local ledger data, rather than verifying all program conditions. This extraction maintains verification accuracy for critical conditions while eliminating redundant checks, thus improving system performance.
Solution Approach 2:
The patent applies partial action by verifying only the necessary restrictive conditions rather than all program conditions. The system identifies that not all program conditions require verification against the ledger - only those that represent critical business rules (restrictive conditions). This partial verification approach maintains sufficient accuracy for transaction validation while significantly reducing the verification workload and improving system performance.
Data Source
Figure 1
Figure 2A
Figure 2B
AI summary
Embodiments of this application provide a method and an apparatus for running a smart contract. The method is applied to a distributed network, and includes: receiving, by a processing node in the distributed network, a transaction sent by a consensus service node, where the transaction includes a plurality of running results generated in an endorsement process of the smart contract; checking, by the processing node, whether the plurality of running results meet a verification policy, where the checking includes checking version numbers and data that are in the plurality of running results and that are generated by a program other than a restrictive condition in the smart contract; when the plurality of running results meet the verification policy, identifying, by the processing node, the restrictive condition in the smart contract, and determining whether local ledger data meets the restrictive condition; and when the local ledger data meets the restrictive condition, accepting, by the processing node, the transaction. According to the method and the apparatus for running a smart contract in the embodiments of this application, a success rate of writing a transaction to a ledger can be increased, and overall system performance can be improved.