A method for smart contract execution in a data asset transaction

Abstract

The application discloses a kind of intelligent contract execution methods in data asset transaction, belong to intelligent contract execution technical field, comprising: according to the multiple transaction nodes triggered when intelligent contract execution, according to the credit value of each transaction node historical transaction execution judgment, to carry out hierarchical selection, obtain verification layer and execution layer, verification layer and execution layer all include multiple transaction nodes;Based on each transaction node of verification layer, the legality verification of signature is executed, and the legality verification pass rate is compared with the first threshold value;In response to the legality verification pass rate greater than or equal to the first threshold value, based on the multiple transaction nodes of execution layer, extract part of transaction node to execute cross-validation, and the cross-validation pass rate is compared with the second threshold value;If cross-validation pass rate is less than the second threshold value, then based on the cross-validation of all transaction nodes of execution layer, for transaction execution judgment;If cross-validation pass rate is greater than or equal to the second threshold value, then transaction execution.

Description

Technical Field

[0001] This invention belongs to the field of smart contract execution technology, and specifically relates to a smart contract execution method in data asset transactions. Background Technology

[0002] With the development of the digital economy, data assets are gradually becoming a core production factor for enterprises, and the scale and frequency of data asset transactions continue to grow. As a core component of blockchain technology, smart contracts, due to their decentralized, automatic execution, and immutable characteristics, have become a key technical means to ensure the credibility of data asset transactions.

[0003] In public blockchain solutions like Ethereum, users need to write their own smart contract code, compile it, and deploy it to the blockchain. When a transaction triggers preset conditions, all nodes in the network must simultaneously verify the transaction's legitimacy. Once verified, the contract is executed, and the result is written to the blockchain. Due to the decentralized nature of public blockchains, each transaction requires verification and recording by all nodes across the network, resulting in extremely low transaction throughput. Public blockchains like Ethereum can only process a limited number of transactions per second, failing to meet the high concurrency demands of peak data asset trading periods and severely impacting transaction timeliness. Furthermore, the local execution and verification of smart contracts also affect the performance of the blockchain system.

[0004] Furthermore, the consortium blockchain network is jointly maintained by multiple organizations, and the deployment and execution of smart contracts require the consent of a majority of nodes within the consortium blockchain. During a transaction, the smart contract automatically verifies the identities and asset balances of both parties, and completes the transaction and updates the on-chain data after confirming that everything is correct.

[0005] However, the aforementioned improvements still have the following shortcomings. First, while most solutions reduce the number of nodes participating in consensus through node grouping or reputation screening, high-reputation nodes, once they enter the core consensus layer, may monopolize it for a long time, posing a risk of targeted corruption by attackers. Second, in terms of batch transaction verification, existing solutions mostly remain at the level of verifying the entire batch of transactions, making it difficult to effectively prevent malicious nodes from forging transaction batches while ensuring high throughput.

[0006] In summary, the above solutions cannot simultaneously meet the combined needs of data asset trading pairs for execution efficiency, system security, and contract flexibility. Summary of the Invention

[0007] This invention provides a smart contract execution method for data asset transactions, which significantly improves consensus efficiency while ensuring transaction security. This solves the problem of low consensus efficiency caused by all nodes needing to participate in full transaction verification, which leads to insufficient system throughput and unmet high-frequency transaction demands in data asset transaction scenarios.

[0008] The technical solution adopted in this invention is as follows:

[0009] A method for executing smart contracts in data asset transactions includes the following steps:

[0010] Based on the smart contract obtained from the user's input transaction requirements and data asset characteristics, multiple transaction nodes are obtained when the smart contract is executed. The reputation value is determined based on the historical transaction execution of each transaction node, and a layered selection is performed. A portion of the transaction nodes are selected from the largest to the smallest to form a verification layer, and the remaining transaction nodes are used to form an execution layer, resulting in a verification layer and an execution layer. Both the verification layer and the execution layer contain multiple transaction nodes.

[0011] For each transaction node in the verification layer, signature validity verification is performed, and the validity verification pass rate is compared with a first threshold.

[0012] In response to a legality verification pass rate greater than or equal to a first threshold, based on multiple transaction nodes in the execution layer, a portion of the transaction nodes are selected for cross-validation, and the cross-validation pass rate is compared with a second threshold.

[0013] If the cross-validation pass rate is less than the second threshold, then cross-validation is performed based on all transaction nodes in the execution layer for transaction execution judgment;

[0014] If the cross-validation pass rate is greater than or equal to the second threshold, the transaction is executed.

[0015] The smart contract execution method for data asset transactions used in this invention also includes the following additional technical features:

[0016] A reputation score is obtained based on the historical transaction execution data of each transaction node for tiered selection, specifically as follows:

[0017] Based on the reputation value, the multiple transaction nodes are sorted, and a portion of the transaction nodes are selected from largest to smallest to form a verification layer, and the remaining transaction nodes form an execution layer.

[0018] The number of transaction nodes in the verification layer is less than that in the execution layer.

[0019] The reputation value is obtained based on the historical transaction execution of each transaction node, specifically as follows:

[0020] When the transaction node is the first time the smart contract is triggered, the reputation value is set to a preset reputation value;

[0021] When the transaction node is not triggered for the first time by the smart contract, the reputation value of the transaction node in the previous consensus period is multiplied by a time decay factor, where the time decay factor is less than 1.

[0022] The reputation value for the current consensus cycle is updated by combining the behavioral scores of the transaction nodes in the previous consensus cycle with the penalty items.

[0023] The penalty item is obtained by the malicious behavior penalty coefficient of the transaction node in the previous consensus cycle, and the malicious behavior penalty coefficient is obtained by signature legality verification and / or cross-verification.

[0024] The specific penalty coefficient for malicious behavior is as follows:

[0025] If the behavior score of a transaction node decreases by more than a preset percentage in two consecutive consensus cycles, the malicious behavior penalty coefficient of the transaction node will be increased.

[0026] If a transaction node's behavior score is greater than or equal to a preset score for three consecutive consensus cycles, the malicious behavior penalty coefficient of the transaction node is reduced, and the malicious behavior penalty coefficient is greater than or equal to 0.

[0027] The signature validity verification includes Merkle root signature consensus verification;

[0028] The cross-validation includes at least one of the following: verification of the legality of the signatures of both parties to the transaction, ownership of data assets, and verification of the execution conditions of smart contract terms.

[0029] The cross-validation also includes hash differential digest collision verification.

[0030] Cross-validation is performed based on all transaction nodes in the execution layer for transaction execution determination, specifically as follows:

[0031] If the cross-validation pass rate of all transaction nodes in the execution layer is less than the second threshold, then based on the cross-validation results, illegal transaction nodes are identified, a rollback operation is performed, and the reputation value of the transaction nodes is updated.

[0032] Otherwise, execute the transaction.

[0033] The smart contract, derived from user-inputted transaction requests and data asset characteristics, is specifically as follows:

[0034] Based on a pre-set smart contract template library, user groups are divided according to the transaction requirements input by users. Based on the template usage frequency of the user groups, a collaborative filtering recommendation score is obtained, and a first candidate template set is obtained.

[0035] Based on a pre-set smart contract template library, and according to the data asset characteristics input by the user, the system obtains a content feature recommendation score based on keyword matching and content similarity, and then filters to obtain a second candidate template set.

[0036] Based on the collaborative filtering recommendation score and the content feature recommendation score, a weighted score is obtained. Based on the first candidate template set and the second candidate template set, the smart contract to be executed is determined.

[0037] Based on the collaborative filtering recommendation score and the content feature recommendation score, a weighted score is obtained, specifically:

[0038] The collaborative filtering recommendation score is assigned a first weight, and the content feature recommendation score is assigned a second weight. The first weight and the second weight are determined based on user groups, data asset characteristics, transaction complexity, and user historical frequency, and are summed to 1.

[0039] The user group includes industries that rely on historical transaction patterns and industries that are sensitive to data content characteristics; the data asset characteristics include real-time data streams and batch data packets.

[0040] The historical transaction pattern relies on an industry with a higher first weight than the data content feature-sensitive industry.

[0041] The first weight corresponding to the real-time data stream is less than that of the batch data packets.

[0042] The first weight is negatively correlated with the transaction complexity and positively correlated with the user's historical frequency.

[0043] The update of the smart contract template library is specifically as follows:

[0044] In response to update commands to the smart contract template library, the system collects data on the frequency of smart contract template usage, user modification records, and unexecuted transaction events over historical time periods.

[0045] The template modification rate and transaction dispute rate are obtained, and a weighted reward function is determined for updating the smart contract template library;

[0046] The template modification rate has a greater weight than the transaction dispute rate.

[0047] A second aspect of the present invention provides an electronic device, comprising:

[0048] Memory, used to store computer instructions;

[0049] A processor is used to implement the smart contract execution method in the data asset transaction when executing the computer instructions.

[0050] Due to the adoption of the above technical solution, the beneficial effects achieved by this invention are as follows:

[0051] 1. In this invention, transaction nodes are selected in a hierarchical manner. Nodes with higher reputation values ​​are designated as the verification layer, while the remaining nodes serve as the execution layer. The verification layer, consisting of a smaller number of nodes, first verifies the signature validity of each transaction batch. Only after successful verification does the execution layer intervene to perform cross-verification. This hierarchical verification mechanism significantly reduces the number of nodes participating in the initial consensus verification, effectively lowers the communication complexity between nodes, and significantly improves consensus efficiency, thereby meeting the high-concurrency processing requirements of data asset trading scenarios.

[0052] After the verification layer completes signature validity verification, the execution layer only selects a subset of nodes for cross-validation. Only when the cross-validation pass rate falls below a second threshold is all nodes in the execution layer triggered to perform cross-validation for transaction execution judgment. This mechanism allows the system to achieve consensus in most normal transaction scenarios without mobilizing all nodes for detailed verification, significantly reducing verification costs. Furthermore, it automatically initiates full verification when the cross-validation pass rate is abnormal, ensuring in-depth investigation of potentially malicious transactions. This achieves effective protection of transaction security with extremely low additional verification costs, balancing efficiency and security.

[0053] Furthermore, the verification layer verifies the signatures of transaction batches to ensure that the batches possess a basic foundation of legitimacy at the overall level. The execution layer employs cross-validation, randomly selecting a subset of nodes for detailed verification to uncover potential issues. When the cross-validation pass rate falls below a second threshold, full verification is automatically triggered to investigate illegal transactions, and transaction execution is determined based on the full verification results. This effectively prevents malicious master nodes from forging transaction batches or a few nodes from colluding to cheat, ensuring that only legitimate and compliant transactions are executed, thus enhancing the overall security of the data asset trading system. Attached Figure Description

[0054] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0055] Figure 1 This is a flowchart illustrating the smart contract execution method in data asset transactions according to one embodiment of the present invention. Detailed Implementation

[0056] To more clearly illustrate the overall concept of the present invention, a detailed description will be provided below with reference to the accompanying drawings and examples.

[0057] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and therefore the scope of protection of the invention is not limited to the specific embodiments disclosed below.

[0058] like Figure 1 As shown, a smart contract execution method in data asset transactions includes the following steps:

[0059] S1: Based on the smart contract obtained from the user's input transaction requirements and data asset characteristics, multiple transaction nodes are obtained when the smart contract is executed. The reputation value is obtained based on the historical transaction execution of each transaction node. In order to perform hierarchical selection, a portion of the transaction nodes are selected from the largest to the smallest to form a verification layer. The remaining transaction nodes are used to form an execution layer, thus obtaining a verification layer and an execution layer. Both the verification layer and the execution layer contain multiple transaction nodes.

[0060] The main purpose of this step is to establish a dynamic evaluation and hierarchical mechanism based on the historical behavior of nodes. In the traditional Byzantine Fault Tolerance (PBFT) consensus algorithm, all consensus nodes participate in the entire verification process of each round of consensus without distinction, resulting in communication complexity increasing quadratically with the number of nodes. Even if attempts are made to reduce the number of nodes participating in consensus through node grouping or reputation screening, the role division between the verification layer and the execution layer is often static or only used when electing the master node.

[0061] This step introduces a reputation score based on historical transaction execution judgments to quantitatively assess node reliability, and dynamically divides nodes into two functional layers based on the assessment results: a verification layer and an execution layer. The verification layer consists of nodes with high reputation scores and is responsible for pre-sorting and initial verification of transactions; the execution layer consists of the remaining nodes and is responsible for subsequent transaction execution.

[0062] The core of this layered strategy lies in separating the verification and execution responsibilities in the consensus process. High-reputation nodes undertake critical verification tasks, thereby reducing the number of nodes participating in core verification in each consensus round while ensuring verification quality. Simultaneously, since both the verification and execution layers contain multiple transaction nodes, system redundancy and Byzantine fault tolerance are preserved, avoiding the risk of single points of failure.

[0063] Data asset trading scenarios are characterized by high frequency and high concurrency. Traditional PBFT algorithms are difficult to meet throughput requirements due to excessive communication overhead. This step, through reputation-driven hierarchical selection, can significantly reduce communication complexity without sacrificing security.

[0064] S2: Perform signature validity verification for each transaction node in the verification layer, and compare the validity verification pass rate with a first threshold.

[0065] The main purpose of this step is to conduct the first security screening of the transaction batch by the verification layer, ensuring that the transaction batch has a basic legal basis at the overall level before it can proceed to the next stage.

[0066] The master node of the verification layer aggregates all transaction data within a time window and calculates the Merkle root. Then, it digitally signs the Merkle root using its private key and broadcasts the signature result to all backup nodes of the verification layer. Each backup node decrypts the signature using the master node's public key and compares the decrypted Merkle root with the Merkle root independently calculated locally based on the transaction data. If they match, the verification is successful.

[0067] Essentially, this process involves compressing a batch of transactions into a fixed-length hash value using the Merkle tree algorithm, and then using this hash value as the sole representative of the entire batch of transactions for rapid consensus. The proportion of verified backup nodes is then tallied; if it exceeds a first threshold, the first phase of consensus is achieved.

[0068] This step uses compression technology to transform large amounts of transaction data into extremely small hash values ​​for verification, significantly reducing network communication overhead. Setting a first threshold (e.g., more than two-thirds of the backup nodes must pass) aims to ensure that the verification results have sufficient consensus support among nodes, preventing a single or a few malicious nodes from forging or tampering with the Merkle root.

[0069] If transaction batches are directly handed over to the execution layer without any prior legality screening, numerous execution layer nodes may perform invalid verifications due to problems with the batches themselves, wasting computational and communication resources. Rapid screening by the verification layer can filter out obviously invalid transaction batches at an early stage.

[0070] S3: In response to the legality verification pass rate being greater than or equal to the first threshold, based on the multiple transaction nodes of the execution layer, some transaction nodes are selected to perform cross-validation, and the cross-validation pass rate is compared with the second threshold.

[0071] The main purpose of this step is to allow the execution layer to perform a more in-depth and detailed verification of the transaction batch, based on the signature validity verification completed at the verification layer, in order to discover potential problems that the verification layer may have missed.

[0072] After consensus is reached, the execution layer nodes asynchronously pull the complete data of the batch of transactions. Each execution layer node randomly selects a certain percentage (e.g., at least 10%) of the transactions from the pulled complete data for detailed verification. The verification content includes the legality of the signatures of the two parties to the transaction, the ownership of data assets, and the execution conditions of smart contract terms.

[0073] This step employs a strategy of selecting a subset of nodes, rather than all nodes, to perform cross-validation. In most normal transaction scenarios, randomly selecting a subset of execution layer nodes for detailed verification is sufficient to identify issues in the batch. Consensus can be achieved without mobilizing all execution layer nodes to participate in detailed verification, thereby significantly reducing verification costs.

[0074] The purpose of setting a second threshold (e.g., 98%) is to set a high pass rate for cross-validation, and only when the pass rate is higher than this threshold is the batch of transactions considered basically safe.

[0075] Step S2 uses the Merkle root's signature consensus to quickly screen transaction batches. This step uses sampling cross-validation to perform in-depth auditing of transaction content. The combination of the two not only retains the high-efficiency consensus advantage brought by hash compression, but also effectively prevents the risk of malicious master nodes forging Merkle roots or a few nodes colluding to cheat through sampling verification.

[0076] Understandably, relying solely on Merkle root signature verification cannot uncover specific issues at the transaction content level, such as an invalid signature or a dispute over asset ownership. Detailed verification is necessary to ensure the legality of each transaction.

[0077] S4: If the cross-validation pass rate is less than the second threshold, then cross-validation is performed based on all transaction nodes of the execution layer for transaction execution judgment;

[0078] If the cross-validation pass rate is greater than or equal to the second threshold, the transaction is executed.

[0079] The main purpose of this step is to dynamically determine whether to trigger a more stringent full validation based on the cross-validation results, thereby achieving an adaptive match between validation strength and anomaly risk. When the cross-validation pass rate is lower than the second threshold, it indicates that the sampling validation has discovered abnormal transactions above the normal level. At this time, the system automatically triggers the full validation mechanism: all execution layer nodes validate all transactions in the batch one by one.

[0080] If the cross-validation pass rate is higher than the second threshold, the execution layer node will officially execute the batch of transactions and update its local state.

[0081] This step introduces a condition-triggered full verification mechanism: Under normal conditions, the system only needs to extract a portion of nodes for cross-validation to complete consensus, maintaining high processing efficiency; under abnormal conditions, the cross-validation pass rate is abnormally low, and the system automatically upgrades the verification strength to full verification, ensuring in-depth investigation of potential malicious transactions.

[0082] Step S3, which involves partial node sampling verification, constitutes Level 1 verification. The condition-triggered full verification in this step constitutes Level 2 verification. If full verification is not triggered and transactions are executed directly when the cross-validation pass rate is low, illegal transactions may pass, leading to data asset loss or system security risks. Conversely, if full verification is executed regardless of the situation, it reverts to the inefficient traditional PBFT model where all nodes verify all transactions. Through the condition-triggered mechanism, this step achieves a better balance between efficiency and security.

[0083] In summary, step S1 narrows down the scope of core verification nodes and reduces communication complexity through reputation-driven hierarchical selection; S2 achieves rapid screening of transaction batches through Merkle root compression and signature consensus; S3 achieves in-depth auditing of transaction content through sampling cross-validation; and S4 effectively mitigates anomaly risks through condition-triggered full verification. Together, these steps significantly improve consensus efficiency while ensuring transaction security, effectively solving the problem of low consensus efficiency caused by the requirement for all nodes to participate in full transaction verification in existing technologies.

[0084] As a preferred embodiment of the present invention, the smart contract obtained based on the user's input transaction requirements and data asset characteristics is specifically as follows:

[0085] Based on a pre-set smart contract template library, user groups are divided according to the transaction requirements input by users. Based on the template usage frequency of the user groups, a collaborative filtering recommendation score is obtained, and a first candidate template set is obtained.

[0086] Based on a pre-set smart contract template library, and according to the data asset characteristics input by the user, the system obtains a content feature recommendation score based on keyword matching and content similarity, and then filters to obtain a second candidate template set.

[0087] Based on the collaborative filtering recommendation score and the content feature recommendation score, a weighted score is obtained. Based on the first candidate template set and the second candidate template set, the smart contract to be executed is determined.

[0088] The main objective of this preferred embodiment is to provide a method for intelligently generating smart contracts for data asset trading scenarios.

[0089] In existing smart contract development models, users need professional coding skills to generate smart contracts that meet their requirements, which presents a high technical barrier. Even with smart contract template libraries, users still need to manually select suitable templates from a large pool and make extensive manual modifications, resulting in low efficiency. Furthermore, existing smart contract template recommendation methods are usually based on predefined contract categories, which are poorly adaptable to emerging contract types and struggle to handle semantically similar but structurally different contracts.

[0090] This implementation introduces recommendation system technology into the smart contract generation process, and achieves intelligent recommendation and customized generation of contract templates through the organic integration of collaborative filtering and content feature analysis.

[0091] First, template recommendation based on collaborative filtering. Based on a pre-defined smart contract template library, user groups are segmented according to their input transaction needs. A collaborative filtering recommendation score is obtained based on the template usage frequency of each user group, resulting in a first-tier candidate template set. Specifically, the k-nearest neighbor algorithm is used to calculate the similarity between the current user and historical users, dividing users into different groups, such as financial institution users and medical research institution users.

[0092] The total historical frequency of each template used by similar neighboring user groups is counted, and the frequency is mapped to the 0-1 range using Min-Max normalization, which is then converted into a collaborative filtering recommendation score. This step utilizes the historical behavioral data of the groups: if a template is frequently used by a group with high similarity, it indicates that the template is highly applicable to that type of user, and recommending it to similar users has a high degree of confidence.

[0093] Collaborative filtering methods are adept at discovering common preference patterns among user groups and can capture transaction needs that are difficult to express directly through content features, such as the implicit preferences of financial institutions for specific settlement cycles or risk control terms.

[0094] Second, template recommendation based on content feature analysis. Based on a pre-set smart contract template library, and according to the characteristics of the user-input data assets, keyword matching is used to obtain a content feature recommendation score based on content similarity, thus filtering out a second set of candidate templates. Specifically, natural language processing technology is used to perform named entity recognition and keyword extraction on the user-input data asset description text. For example, from "3 years of anonymized medical image data, must comply with the EU General Data Protection Regulation (GDPR)," keywords such as "medical image," "anonymization," and "GDPR" are extracted.

[0095] The extracted keywords are matched with preset tags in the template library using TF-IDF cosine similarity, and the similarity is linearly mapped to a content feature recommendation score. When new users have no historical transaction data, collaborative filtering cannot generate effective recommendations, while content feature analysis can generate recommendations based solely on the user's current input description of the data asset. Simultaneously, this step captures the unique attributes of the data asset, such as data type, compliance requirements, and privacy protection level, ensuring that the recommended templates are highly matched to the data asset to be traded at the content level.

[0096] Third, weighted fusion recommendation. A weighted score is obtained based on the collaborative filtering recommendation score and the content feature recommendation score. The smart contract to be executed is determined based on the first candidate template set and the second candidate template set. Specifically, a comprehensive score is calculated by weighted summation, and the optimal template with the highest weighted score is recommended to the user.

[0097] It should be noted that the weighted score is obtained based on the collaborative filtering recommendation score and the content feature recommendation score, as follows:

[0098] The collaborative filtering recommendation score is assigned a first weight, and the content feature recommendation score is assigned a second weight. The first weight and the second weight are determined based on user groups, data asset characteristics, transaction complexity, and user historical frequency, and are summed to 1.

[0099] The user group includes industries that rely on historical transaction patterns and industries that are sensitive to data content characteristics; the data asset characteristics include real-time data streams and batch data packets.

[0100] The historical transaction pattern relies on an industry with a higher first weight than the data content feature-sensitive industry.

[0101] The first weight corresponding to the real-time data stream is less than that of the batch data packets.

[0102] The first weight is negatively correlated with the transaction complexity and positively correlated with the user's historical frequency.

[0103] It should be noted that the initial values ​​of both the first and second weights are set to 0.5, i.e., first weight W1 = 0.5 and second weight W2 = 0.5. These values ​​are adjusted based on the user group, data asset characteristics, transaction complexity, and historical user frequency.

[0104] Historical transaction patterns are industry-dependent. In industries like finance, user transaction behavior exhibits strong regularity and patterns, and historical transaction data can effectively reflect user template preferences. Therefore, collaborative filtering recommendations have high reliability, and the corresponding first weight should be set relatively high. In industries sensitive to data content characteristics, such as healthcare, the content attributes of data assets, such as data type, privacy level, and compliance requirements, play a decisive role in template selection. The reference value of users' historical transaction patterns is relatively limited. Therefore, content feature-based recommendations have high reliability, and the corresponding second weight should be set relatively high.

[0105] Specifically, for the financial industry, the first weight W1 is increased by 0.1, and the second weight W2 is decreased by 0.1, resulting in W1=0.6 and W2=0.4; for the healthcare industry, the first weight W1 is decreased by 0.1, and the second weight W2 is increased by 0.1, resulting in W1=0.4 and W2=0.6.

[0106] The core characteristics of real-time data stream assets lie in their timeliness and dynamism. During transactions, they are highly sensitive to content attributes such as data format, update frequency, and transmission protocols. Historical transaction patterns offer relatively limited reference value; therefore, content feature weights should be set higher, while collaborative filtering weights should be reduced accordingly. Batch data package assets are typically structured static datasets. During transactions, transaction patterns such as delivery methods, billing cycles, and usage periods are highly reusable. Historical transaction data provides strong reference value; therefore, collaborative filtering weights should be set higher, while content feature weights should be reduced accordingly.

[0107] Specifically, for real-time data streams, the first weight W1 is decreased by 0.2 and the second weight W2 is increased by 0.2, resulting in W1=0.3 and W2=0.7; for batch data packets, the first weight W1 is increased by 0.2 and the second weight W2 is decreased by 0.2, resulting in W1=0.7 and W2=0.3.

[0108] Transaction complexity reflects the richness of contract terms and the number of participants. High-complexity transactions typically involve multiple terms and multiple parties. The selection of contract templates requires a high degree of completeness and accuracy in the terms. Content feature analysis can more accurately match the detailed user input requirements with the template's term structure; therefore, the weight of content features should be set higher, while the weight of collaborative filtering should be reduced accordingly. Low-complexity transactions are usually simple buy-sell transactions with simple term structures. Historical templates are highly reusable. Collaborative filtering can quickly recommend suitable templates based on the behavior of similar user groups; therefore, the weight of collaborative filtering should be set higher, while the weight of content features should be reduced accordingly.

[0109] Specifically, for high-complexity transactions, the first weight W1 is decreased by 0.1 and the second weight W2 is increased by 0.1, resulting in W1=0.4 and W2=0.6; for low-complexity transactions, the first weight W1 is increased by 0.2 and the second weight W2 is decreased by 0.2, resulting in W1=0.7 and W2=0.3.

[0110] User historical frequency reflects the amount of user behavior data available to the system. High-frequency users possess rich historical transaction records, enabling collaborative filtering algorithms to accurately calculate user similarity and template usage frequency based on sufficient data, resulting in highly reliable recommendation results. Therefore, the collaborative filtering weight should be set relatively high. New users or low-frequency users lack sufficient historical behavior data, leading to a cold start problem for collaborative filtering and lower reliability of recommendation results. In this case, content feature analysis does not rely on historical data; it can generate recommendations solely based on the user's current input data asset characteristics. Therefore, the content feature weight should be set relatively high. The core basis of this adjustment logic lies in the dependence of collaborative filtering algorithms on data volume: the more abundant the data, the higher the accuracy of collaborative filtering; the sparser the data, the more prominent the independent value of content feature analysis.

[0111] Specifically, for high-frequency users, the first weight W1 is increased by 0.2 and the second weight W2 is decreased by 0.2, resulting in W1=0.7 and W2=0.3; for new users, the first weight W1 is decreased by 0.3 and the second weight W2 is increased by 0.3, resulting in W1=0.2 and W2=0.8.

[0112] The weight adjustment logic of the above four dimensions is independent of each other and complementary to each other. The system can combine the judgment results of the four dimensions through a preset rule table or a lightweight decision tree model, and dynamically calculate the specific values ​​of the first weight and the second weight in each recommendation, and the sum of the two is 1.

[0113] Specifically, for users in the financial industry, real-time data streams, and high-frequency transactions involving high complexity, the weights are adjusted independently in sequence: first weight W1 increases by 0.1, second weight W2 decreases by 0.1; first weight W1 decreases by 0.2, second weight W2 increases by 0.2; first weight W1 decreases by 0.1, second weight W2 increases by 0.1; first weight W1 increases by 0.2, second weight W2 decreases by 0.2. This results in W1=0.5 and W2=0.5.

[0114] In data asset trading scenarios, there are significant differences in user groups, data asset types, transaction complexity, and user historical behavior. These differences directly affect the relative effectiveness of the two recommendation strategies. Using fixed weights makes it impossible to optimize the emphasis of the recommendation strategy for different scenarios, leading to large fluctuations in recommendation accuracy across various situations. By introducing a multi-dimensional dynamic weight adjustment mechanism, the system can adaptively adjust the contribution of the two recommendation strategies according to the specific context of the current transaction, ensuring that the recommendation results are always based on the most reliable source of recommendation information.

[0115] As a preferred embodiment of this implementation, the updating of the smart contract template library specifically involves:

[0116] In response to update commands to the smart contract template library, the system collects data on the frequency of smart contract template usage, user modification records, and unexecuted transaction events over historical time periods.

[0117] The template modification rate and transaction dispute rate are obtained, and a weighted reward function is determined for updating the smart contract template library;

[0118] The template modification rate has a greater weight than the transaction dispute rate.

[0119] The primary objective of this preferred embodiment is to achieve adaptive and continuous optimization of the smart contract template library. In data asset trading scenarios, smart contract templates need to be constantly adjusted in response to changes in industry regulatory policies, evolution of trading models, and shifts in user behavior.

[0120] This embodiment introduces a reinforcement learning mechanism, which utilizes user behavior patterns and transaction result feedback contained in historical transaction data to automatically identify the shortcomings of the templates and make targeted optimizations, enabling the template library to continuously adapt to the dynamic changes in data asset transaction scenarios.

[0121] The system responds to update commands from the smart contract template library by collecting three core data points over historical time periods. Smart contract template usage frequency reflects the activity level of each template in user selection; frequently used templates indicate high versatility and user acceptance. User modification records reflect the gap between templates and actual user needs, specifically the template modification rate. If a template's terms are frequently modified by users, it indicates a discrepancy between the template's default settings and user expectations, requiring optimization. Unexecuted transaction events reflect potential defects or ambiguities in the template's practical application, specifically the transaction dispute rate. A high proportion of transaction disputes associated with a template indicates deficiencies in the template's terms and the definition of rights and responsibilities. These three data points characterize the template's actual performance from different dimensions: usage frequency reflects the template's popularity, modification rate reflects the accuracy of the template's match with user needs, and dispute rate reflects the template's legal rigor and enforceability.

[0122] The collected data is quantified into two key indicators: template modification rate and transaction dispute rate. A reinforcement learning reward function is constructed using a weighted average. The template modification rate has a greater weight than the transaction dispute rate, indicating that the system prioritizes optimizing user modification frequency (i.e., reducing user workload) while also considering the transaction dispute rate (i.e., improving the rigor of contract terms). This weighting configuration reflects an optimization philosophy centered on user experience and guaranteed by transaction security. A higher reward function value indicates better overall template performance. The optimization goal is to maximize the reward function, and through multiple rounds of iterative training, the structure of the template library and default terms continuously approach the optimal state.

[0123] The system aims to maximize the reward function and optimizes the basic structure of the template through multiple rounds of iterative training, stopping training when the loss function converges. Optimization includes two aspects: clause priority ranking and parameter default value setting. Clause priority ranking places frequently modified clauses at the top, allowing users to quickly locate and adjust them when generating contracts. Parameter default value setting involves assigning reasonable default values ​​to configurable parameters in the template based on the most frequently used values ​​from historical data. The optimized template is then updated to the template library.

[0124] In a preferred embodiment of the present invention, a reputation value is obtained based on the historical transaction execution of each transaction node for hierarchical selection, specifically as follows:

[0125] Based on the reputation value, the multiple transaction nodes are sorted, and a portion of the transaction nodes are selected from largest to smallest to form a verification layer, and the remaining transaction nodes form an execution layer.

[0126] The number of transaction nodes in the verification layer is less than that in the execution layer.

[0127] The main purpose of this preferred implementation is to establish a dynamic evaluation and hierarchical mechanism based on the historical behavior of nodes, separating the verification responsibility from the execution responsibility in the consensus process.

[0128] In the traditional PBFT consensus algorithm, all consensus nodes participate in the entire verification process of each round of consensus without distinction. Nodes need to communicate with each other, causing the communication complexity to increase quadratically with the number of nodes. Existing improved schemes based on grouping strategies reduce communication overhead by decreasing the number of consensus participating nodes, but the role division between the verification layer and the execution layer is often static or only used during the election of the master node.

[0129] This implementation introduces a reputation-driven sorting and hierarchical mechanism to dynamically allocate node roles. High-reputation nodes undertake critical verification tasks, while the remaining nodes handle execution tasks. This reduces the number of nodes participating in core verification in each consensus round while ensuring verification quality. The fact that the number of transaction nodes in the verification layer is less than that in the execution layer ensures that only a few high-reputation nodes participate in the core verification process, fundamentally reducing communication complexity.

[0130] The system maintains a dynamic reputation value for each consensus node, which comprehensively reflects the node's behavior during the historical consensus process. At the beginning of each consensus cycle, the system sorts all nodes in descending order of their reputation values. Nodes with higher reputation values ​​are more reliable in their historical consensus performance and are more suitable for undertaking critical verification tasks.

[0131] Based on the ranking results, the system selects a subset of transaction nodes from largest to smallest to form the verification layer, and the remaining transaction nodes form the execution layer. The number of transaction nodes in the verification layer is less than that in the execution layer. The verification layer consists of high-reputation nodes with high rankings, responsible for pre-sorting and initial verification of transactions, and undertaking the core verification responsibilities in the consensus process. The execution layer consists of the remaining nodes, responsible for receiving and executing batches of transactions that have reached consensus, and undertaking the execution responsibilities of data verification and forwarding. This structural design, where the number of nodes in the verification layer is less than that in the execution layer, ensures that only a few high-reputation nodes participate in the core verification process, thereby controlling the communication scale in the consensus process from the source.

[0132] At the end of each consensus cycle, the system recalculates the reputation value based on the nodes' behavior during that cycle, and re-sorts and stratifies them at the start of the next new cycle. The set of nodes in the verification layer is dynamically adjusted at the end of each cycle, realizing the periodic rotation of the verification layer.

[0133] The verification layer consists of nodes with the highest reputation scores. These nodes have demonstrated the highest reliability in historical consensus processes, and their participation in verification carries high credibility. Compared to methods that randomly select verification nodes or select nodes solely based on stake, a reputation-driven selection mechanism better guarantees verification quality.

[0134] As a preferred embodiment of this implementation, the reputation value is obtained based on the historical transaction execution of each transaction node, specifically as follows:

[0135] When the transaction node is the first time the smart contract is triggered, the reputation value is set to a preset reputation value;

[0136] When the transaction node is not triggered for the first time by the smart contract, the reputation value of the transaction node in the previous consensus period is multiplied by a time decay factor, where the time decay factor is less than 1.

[0137] The reputation value for the current consensus cycle is updated by combining the behavioral scores of the transaction nodes in the previous consensus cycle with the penalty items.

[0138] The penalty item is obtained by the malicious behavior penalty coefficient of the transaction node in the previous consensus cycle, and the malicious behavior penalty coefficient is obtained by signature legality verification and / or cross-verification.

[0139] This embodiment introduces a collaborative design of a time decay factor and a malicious behavior penalty coefficient, enabling the reputation value to reasonably decay the historical impact and respond quickly to malicious behavior, thereby improving the system's sensitivity to node state changes and its deterrent effect against malicious behavior.

[0140] When a transaction node is triggered for the first time by a smart contract, that is, when the node participates in the consensus process for the first time, the system has no historical behavior data for the node to refer to. At this time, the system sets a preset reputation value as an initial value for the node. This preset value can be set according to the system's security policy; for example, the initial value can be set to 100 points. This initialization strategy solves the cold start problem when a new node joins, ensuring that new nodes can participate in the consensus process equally and have the opportunity to demonstrate their behavior.

[0141] When a transaction node triggers a non-smart contract for the first time, meaning the node has already participated in the historical consensus process, the system updates the reputation value for the current period based on three dimensions: reputation value, behavior score, and penalty items from the previous period. The specific update method is as follows.

[0142] The reputation value of a transaction node in the previous consensus period is multiplied by a time decay factor. The time decay factor is a positive number less than 1, ranging from 0.7 to 0.9. This factor controls the degree to which historical reputation values ​​influence current reputation: the larger the factor value, the slower the impact of historical behavior on current reputation decays; the smaller the factor value, the faster historical reputation is forgotten. This design ensures that a node's historical reputation does not permanently affect its current evaluation, focusing more on the node's recent performance.

[0143] Based on the decayed historical reputation, the score is combined with the node's behavioral score from the previous consensus cycle. The behavioral score comprehensively considers multiple performance dimensions of the node in the previous cycle, including online time, number of consensus rounds participated in, voting accuracy rate, and transaction completion rate, and is calculated by weighting after normalization. This score reflects the node's actual behavioral performance in the previous cycle.

[0144] Based on the behavior score, a penalty term is further subtracted. The penalty term is obtained through the malicious behavior penalty coefficient of the transaction node in the previous consensus cycle. The malicious behavior penalty coefficient is determined based on the results of signature validity verification and / or cross-validation: when a node exhibits Byzantine behavior (such as inconsistent voting results with the final consensus, propagation of invalid transactions, etc.), the penalty coefficient is positive; otherwise, it is 0. The penalty weight λ is used to amplify the penalty effect and has a value of 1.2.

[0145] Specifically, ,

[0146] Wherein, γ is the time decay factor, with a value ranging from 0.7 to 0.9; Let be the reputation value of node i at the beginning of period t; Score the behavior of node i in period t; λ is the penalty coefficient for malicious behavior of node i in period t, with a value ranging from 0 to 0.5; λ is the penalty weight.

[0147] The system also includes a dynamic enhancement and recovery mechanism for the penalty coefficient. Specifically, the penalty coefficient for malicious behavior is as follows:

[0148] If the behavior score of a transaction node decreases by more than a preset percentage in two consecutive consensus cycles, the malicious behavior penalty coefficient of the transaction node will be increased.

[0149] If a transaction node's behavior score is greater than or equal to a preset score for three consecutive consensus cycles, the malicious behavior penalty coefficient of the transaction node is reduced, and the malicious behavior penalty coefficient is greater than or equal to 0.

[0150] If a node's behavior score drops by more than a preset percentage (e.g., a 20% decrease) over two consecutive consensus cycles, the system automatically increases the node's malicious behavior penalty coefficient (e.g., by 0.1), thereby accelerating the decline in the low-reputation node's reputation value and causing it to be removed from the high-reputation node ranks more quickly. Conversely, if a node's behavior score returns to normal levels over three consecutive consensus cycles, the system gradually reduces its malicious behavior penalty coefficient until it reaches zero. This mechanism allows the penalty intensity to dynamically change based on the node's behavioral trends.

[0151] This embodiment achieves a synergistic effect by coupling the time decay factor and the malicious behavior penalty coefficient: the time decay factor allows the system to reasonably forget historical behaviors and pay more attention to the recent performance of nodes; the malicious behavior penalty coefficient enables the system to punish malicious behaviors immediately and with a cumulative effect. The combination of the two allows the reputation model to both reasonably forget the past and quickly respond to malicious behaviors.

[0152] As a preferred embodiment of the present invention, the signature validity verification includes Merkle root signature consensus verification;

[0153] The cross-validation includes at least one of the following: verification of the legality of the signatures of both parties to the transaction, ownership of data assets, and verification of the execution conditions of smart contract terms.

[0154] The cross-validation also includes hash differential digest conflict verification. Specifically, hash differential digest conflict verification involves the following steps: After simulating the execution of sampled transactions, the execution layer nodes sort the changed key-value pairs in their local state database lexicographically and generate a state root hash using a Merkle Patricia Trie. This state root hash is the differential digest. Each execution layer node broadcasts the generated differential digest to other sampled nodes in the same group. If the differential digest generated by a node is inconsistent with the digests generated by at least two-thirds of the nodes in the group, a secondary verification is triggered: the node must send its entire simulated read-write set to other nodes in the group for traceability. If the traceability confirms that the node's read-write set contains erroneous state changes, the node is directly identified as a Byzantine node, and the malicious behavior penalty coefficient is increased.

[0155] Signature validity verification includes Merkle root signature consensus verification. This verification is performed at the verification layer, and the specific implementation strategy is as follows: The verification layer master node aggregates all transaction data within a preset time window and calculates the Merkle root of the batch of transaction data using the Merkle tree algorithm. The Merkle root is a hash value that compresses a batch of transactions into a fixed length using the Merkle tree algorithm. This process compresses a large amount of transaction data into a very small hash digest, which serves as the unique representative of the entire batch of transactions. Subsequently, the master node digitally signs the Merkle root using a hash algorithm, that is, it encrypts the Merkle root value with the master node's private key to generate a digital signature. The master node broadcasts the signed Merkle root (i.e., the Merkle root value plus the digital signature) to all backup nodes in the verification layer.

[0156] Upon receiving the broadcast, each backup node performs the following operations: decrypts the signature using the master node's public key to obtain the decrypted Merkle root value; compares the Merkle root value calculated locally based on the received transaction data; if the two values ​​match, it indicates that the Merkle root of this batch of transactions was indeed signed by the master node and has not been tampered with, and the verification passes; if they do not match, the verification fails, indicating that the master node may have acted maliciously or that the data transmission was incorrect.

[0157] The percentage of verified backup nodes is counted. If it exceeds a preset first threshold (e.g., two-thirds), the first phase of consensus is achieved, confirming the validity of the Merkle root for that batch of transactions. This verification mechanism essentially checks the legitimacy of the master node's behavior, preventing the master node from forging the Merkle root or tampering with the transaction batch.

[0158] Cross-validation includes at least one of the following: verification of the legality of signatures of both parties to the transaction, ownership of data assets, and verification of the execution conditions of smart contract terms. Cross-validation also includes hash differential digest collision verification. This verification is performed at the execution layer, and the specific implementation strategy is as follows: After consensus is reached at the verification layer, the execution layer nodes asynchronously pull the complete data of the batch of transactions from shared storage or the verification layer nodes. Each execution layer node randomly selects a certain percentage (e.g., at least 10%) of the pulled complete data for detailed verification.

[0159] The detailed verification includes verifying the legality of the signatures of both parties (confirming the authenticity and validity of the digital signatures of the transaction initiator and recipient), verifying the ownership of the data assets (confirming that the data assets to be traded do indeed belong to the seller and that ownership is clear), and verifying the execution conditions of the smart contract terms (confirming that the preconditions for triggering contract execution have been met, such as the receipt of funds). These verifications cover the most critical security elements in data asset transactions: signature legality ensures the authenticity of the transaction parties, ownership verification ensures the legality of the transaction object, and verification of the execution conditions ensures the correctness of the transaction logic.

[0160] Simultaneously, each execution layer node calculates the state hash differential digest after the verified transaction execution, which is the hash digest of the global state changes after executing the batch of transactions, and exchanges the differential digests with each other. The state hash differential digest is a compressed representation of the state changes generated by transaction execution, compressing the state change data into a fixed-length hash value through a hash algorithm.

[0161] If a node's differential digest is inconsistent with that of the majority of other nodes, the node is directly identified as a Byzantine node, and its reputation value is lowered and its penalty coefficient is increased. This mechanism allows the system to quickly identify malicious nodes in the execution layer without verifying all states.

[0162] In a preferred embodiment of the present invention, cross-validation is performed based on all transaction nodes of the execution layer for transaction execution determination, specifically as follows:

[0163] If the cross-validation pass rate of all transaction nodes in the execution layer is less than the second threshold, then based on the cross-validation results, illegal transaction nodes are identified, a rollback operation is performed, and the reputation value of the transaction nodes is updated.

[0164] Otherwise, execute the transaction.

[0165] The main objective of this preferred implementation is to establish a transaction execution judgment and anomaly handling mechanism based on cross-validation pass rate adaptive triggering. By setting a second threshold as a triggering condition, the system can adaptively decide whether to execute the transaction or trigger full validation and rollback based on the cross-validation pass rate, and synchronously update the node reputation value when an anomaly occurs, thus realizing a closed-loop linkage of validation, decision-making, handling, and reputation assessment.

[0166] After some nodes in the execution layer complete sampling cross-validation, the system calculates the proportion of nodes with a cross-validation pass rate lower than a second threshold. The cross-validation pass rate refers to the proportion of successfully validated transactions in each execution layer node's sample transactions out of the total number of samples. The system compares this proportion with a preset fault tolerance limit. For example, the second threshold is 98%, and the fault tolerance limit is one-third.

[0167] If the cross-validation pass rate of all transaction nodes in the execution layer is less than the second threshold, it indicates that the sampling verification has detected abnormal transactions exceeding the normal level. The system determines that this batch of transactions poses a risk and triggers the full verification mechanism. Specifically, all execution layer nodes verify each transaction in the batch one by one, covering the legality of the signatures of both parties, ownership of data assets, and execution conditions of smart contract terms. If at least one illegal transaction is found after full verification, a rollback operation is performed, rolling back all transactions in the batch. The rollback operation ensures that illegal transactions are not ultimately executed, protecting the data asset security and financial security of both parties.

[0168] The rollback operation is specifically implemented based on the MVCC (Multi-Version Concurrency Control) mechanism: Before each transaction is executed, the system generates a global version number for the current world state and temporarily stores the write operations (WriteSet) in progress in a memory buffer pool, without immediately writing them to disk. When all transactions are verified and an illegal transaction is found, the system discards all write operations in the current buffer pool, rolls back the global version number to the state before the transaction was executed, and adds the nodes involved in the illegal transaction to the blacklist candidate. When all transactions are determined to be legal, the system writes the write operations in the buffer pool to the underlying database in batches, increments the global version number by 1, and completes the state commit.

[0169] After triggering full verification and detecting illegal transactions, the system identifies the illegal transaction nodes based on the cross-validation results, records the information of the malicious nodes, and updates the reputation value of the transaction nodes. Specifically, the system significantly increases the penalty coefficient for malicious behavior of malicious nodes, for example, by 0.3.

[0170] If the cross-validation pass rate is greater than or equal to the second threshold and there are no differential digest conflicts, the batch of transactions is deemed safe, and the execution layer nodes officially execute the batch of transactions and update their local states. At this point, there is no need to trigger full validation, and the system completes consensus confirmation for a large number of transactions with low validation cost.

[0171] This invention also provides an electronic device, comprising:

[0172] Memory, used to store computer instructions;

[0173] A processor is used to implement the smart contract execution method in the data asset transaction when executing the computer instructions.

[0174] Therefore, any of the technical effects of the smart contract execution methods in the above-mentioned data asset transactions can be achieved, which will not be elaborated here.

[0175] For any parts not mentioned in this invention, existing technologies can be used or referenced.

[0176] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0177] The above description is merely an embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.

Claims

1. A method for executing smart contracts in data asset transactions, characterized in that, Includes the following steps: Based on the smart contract derived from user-input transaction requirements and data asset characteristics, multiple transaction nodes are obtained when the smart contract is executed. A reputation value is determined based on the historical transaction execution of each transaction node for hierarchical selection. A portion of the transaction nodes are selected from largest to smallest to form a verification layer, and the remaining transaction nodes form an execution layer, resulting in a verification layer and an execution layer. Both the verification layer and the execution layer contain multiple transaction nodes, with the number of transaction nodes in the verification layer being less than that in the execution layer. Specifically, a reputation value is obtained based on the historical transaction execution of each transaction node. When a transaction node is the first to trigger the smart contract, its reputation value is set to a preset reputation value. When a transaction node is not the first to trigger the smart contract, its reputation value from the previous consensus period is multiplied by a time decay factor, where the time decay factor is less than 1. The reputation value for the current consensus period is updated by combining the transaction node's behavior score from the previous consensus period with a penalty item. The penalty item is obtained through the malicious behavior penalty coefficient of the transaction node in the previous consensus period, which is obtained based on signature validity verification and / or cross-validation. For each transaction node in the verification layer, signature validity verification is performed, and the validity verification pass rate is compared with a first threshold. In response to a legality verification pass rate greater than or equal to a first threshold, based on multiple transaction nodes in the execution layer, a portion of the transaction nodes are selected to perform cross-validation, and the cross-validation pass rate is compared with a second threshold. If the cross-validation pass rate is less than the second threshold, cross-validation is performed on all transaction nodes in the execution layer for transaction execution judgment. Specifically, if the cross-validation pass rate of all transaction nodes in the execution layer is less than the second threshold, illegal transaction nodes are identified based on the cross-validation results, a rollback operation is performed, and the reputation value of the transaction nodes is updated; otherwise, the transaction is executed. If the cross-validation pass rate is greater than or equal to the second threshold, the transaction is executed.

2. The smart contract execution method in data asset transactions according to claim 1, characterized in that, The specific penalty coefficient for malicious behavior is as follows: If the behavior score of a transaction node decreases by more than a preset percentage in two consecutive consensus cycles, the malicious behavior penalty coefficient of the transaction node will be increased. If a transaction node's behavior score is greater than or equal to a preset score for three consecutive consensus cycles, the malicious behavior penalty coefficient of the transaction node is reduced, and the malicious behavior penalty coefficient is greater than or equal to 0.

3. The smart contract execution method in data asset transactions according to claim 1, characterized in that, The signature validity verification includes Merkle root signature consensus verification; The cross-validation includes at least one of the following: verification of the legality of the signatures of both parties to the transaction, ownership of data assets, and verification of the execution conditions of smart contract terms. The cross-validation also includes hash differential digest collision verification.

4. The smart contract execution method in data asset transactions according to claim 1, characterized in that, The smart contract, derived from user-inputted transaction requests and data asset characteristics, is specifically as follows: Based on a pre-set smart contract template library, user groups are divided according to the transaction requirements input by users. Based on the template usage frequency of the user groups, a collaborative filtering recommendation score is obtained, and a first candidate template set is obtained. Based on a pre-set smart contract template library, and according to the data asset characteristics input by the user, the system obtains a content feature recommendation score based on keyword matching and content similarity, and then filters to obtain a second candidate template set. Based on the collaborative filtering recommendation score and the content feature recommendation score, a weighted score is obtained. Based on the first candidate template set and the second candidate template set, the smart contract to be executed is determined.

5. The smart contract execution method in data asset transactions according to claim 4, characterized in that, The weighted score is obtained based on the collaborative filtering recommendation score and the content feature recommendation score, as follows: The collaborative filtering recommendation score is assigned a first weight, and the content feature recommendation score is assigned a second weight. The first weight and the second weight are determined based on user groups, data asset characteristics, transaction complexity, and user historical frequency, and are summed to 1. The user group includes industries that rely on historical transaction patterns and industries that are sensitive to data content characteristics; the data asset characteristics include real-time data streams and batch data packets. The historical transaction pattern relies on an industry with a higher first weight than the data content feature-sensitive industry. The first weight corresponding to the real-time data stream is less than that of the batch data packets. The first weight is negatively correlated with the transaction complexity and positively correlated with the user's historical frequency.

6. The smart contract execution method in data asset transactions according to claim 4, characterized in that, The update of the smart contract template library is specifically as follows: In response to update commands to the smart contract template library, the system collects data on the frequency of smart contract template usage, user modification records, and unexecuted transaction events over historical time periods. The template modification rate and transaction dispute rate are obtained, and a weighted reward function is determined for updating the smart contract template library; The template modification rate has a greater weight than the transaction dispute rate.

7. An electronic device, characterized in that, include: Memory, used to store computer instructions; A processor, configured to implement the smart contract execution method in data asset transactions as described in any one of claims 1 to 6 when executing the computer instructions.

Images