A financial transaction verification method and system of a trusted smart contract

Abstract

The application discloses a kind of financial transaction verification method and system of trusted smart contract, it is related to blockchain financial transaction verification technical field.The method includes: in response to digital asset transfer request, according to asset issuer identification and asset receiver identification from blockchain network determines trusted execution node set;With financial transaction verification system as coordination center, trusted execution node set as verification source point, digital asset transfer request as verification terminal, build verification directed weighted graph;According to the verification capacity of edge in each verification path, determine multiple parallel verification sub-paths by multi-path parallel verification share allocation;According to the verification capacity of parallel verification sub-path, determine trusted verification result, and in response to confirmation operation trigger smart contract execution.The system includes memory and processor, and when executing, the above method steps are realized.Through graph structure modeling and parallel path allocation, trusted convergence of asset verification is realized in the network coexisting with untrusted node.

Description

Technical Field

[0001] This invention relates to the field of blockchain financial transaction verification technology, specifically to a method and system for verifying financial transactions using trusted smart contracts. Background Technology

[0002] In the process of transferring digital assets based on blockchain, the execution of smart contracts relies on external verification to confirm the qualifications, intentions, and legality of the asset status of both parties in the transaction. Most existing verification schemes use a single oracle or a pre-set fixed set of validators, concentrating the entire verification workload on at least a few entities. This design makes the reliability of the entire verification process directly limited by the single point of trust of the selected entity. Once a validator node acts maliciously or is attacked, the transfer is at risk of being manipulated.

[0003] Traditional verification mechanisms fail to integrate and model the historical behavior, real-time pricing, and time response characteristics of verification nodes, resulting in a lack of detailed characterization of dynamic trust relationships in node selection. There is a lack of effective capacity sharing and collaboration channels among verifiers; asset amounts are typically packaged as a whole and handled independently by a single verifier. This prevents the system from automatically breaking down verification tasks to enable parallel processing among multiple verifiers when a single node's verification capacity is insufficient to cover large assets, creating a rigid bottleneck in verification load and uncontrollable increases in verification latency. Furthermore, the lack of means to abstract coordinating and verifying nodes into a graph structure and quantify the capacity of each edge prevents the system from planning the optimal verification flow distribution path from a global perspective. This leads to low verification resource utilization and difficulty in providing aggregated proofs for user interaction and confirmation before verification results are uploaded to the blockchain. Summary of the Invention

[0004] The purpose of this invention is to provide a financial transaction verification method and system for trusted smart contracts. In a blockchain network environment where untrusted nodes coexist, a directed weighted graph containing a coordination center, a verification source point, and a verification endpoint is constructed based on the asset transfer request. Based on the verification capacity of the edges in the graph, a multi-path parallel verification share allocation is performed, thereby generating an aggregated verification result that can be confirmed and triggering the execution of the smart contract.

[0005] To achieve the above objectives, the present invention provides the following technical solution: The present invention provides a financial transaction verification method and system for trusted smart contracts. When a digital asset transfer request is received, based on the asset issuer identifier and asset recipient identifier carried in the request, a set of trusted execution nodes participating in the current financial transaction verification is dynamically determined from the blockchain network. The financial transaction verification system is used as the coordination center, the set of trusted execution nodes is used as the verification source point, and the digital asset transfer request is used as the verification endpoint. A directed weighted graph for verification is constructed, and multiple parallel verification sub-paths are obtained through a multi-path parallel verification share allocation method according to the verification capacity of each verification path in the graph. The trusted verification result is then determined. After obtaining the confirmation operation of the displayed trusted verification result, the corresponding smart contract is executed, thereby realizing the reasonable scheduling of verification resources and the efficient and trusted verification process.

[0006] As a technical solution of the present invention, when determining the set of trusted execution nodes, candidate execution nodes that are registered in the blockchain network and have historical transaction verification relationships with both the asset issuer and the asset recipient are queried. Based on the number of times and frequency of historical verification of each candidate execution node, a set of trusted execution nodes for financial transaction verification is dynamically selected from the candidate execution nodes. This ensures that the nodes participating in the verification have both the relevance to the two parties to the transaction and the execution reliability reflected by the frequent delegation.

[0007] In constructing the directed weighted graph for verification, this invention comprehensively determines the dynamic verification reliability factor, verification cost edge weight, and verification timeliness edge weight for each trusted execution node. This yields the verification capacity from each verification source point to the coordination center edge. Simultaneously, the verification capacity from the verification endpoint to the coordination center edge is determined based on the asset amount, thus forming the directed weighted graph for verification. Preferably, the process of determining the dynamic verification reliability factor includes: obtaining the basic accuracy rate based on the ratio of the number of correct verifications within a historical sliding time window to the total number of verifications; determining the delay fluctuation deviation value based on the difference between historical response delay and average response delay; obtaining the delay attenuation coefficient by combining the delay attenuation mapping relationship; and using the product of the basic accuracy rate and the delay attenuation coefficient as the dynamic verification reliability factor, ensuring that the reliability factor accurately reflects the current verification reliability of the node.

[0008] The cost edge weight for verification is determined based on the ratio of the verification quote from each node to the weighted average verification quote for the digital asset transfer request, to the verification quote diameter, and the cost weight decay coefficient corresponding to the preset deviation threshold range of this ratio. The weighted average verification quote is calculated by adaptively calculating the quote time decay weight for each node using the verification quote volatility and the time decay offset of the quote from the current time, and then summing them up. This ensures that both the time freshness and volatility characteristics of the verification quote are included in the cost measurement. The preset deviation threshold range can include low, medium, and high deviation ranges. The low deviation range corresponds to a higher cost weight decay coefficient, followed by the medium deviation range, and the high deviation range has the lowest. This assigns higher cost edge weights to nodes whose quotes are closer to the weighted average, guiding the system to select verification nodes with reasonable costs.

[0009] The verification timeliness edge weight is determined based on the timeout decay rate of each node and the difference between its promised verification completion time and its expected verification completion time. The timeout decay rate is obtained by the ratio of the number of historical timeout verifications to the total number of historical verifications, allowing the timeliness weight to penalize nodes with a high number of historical timeouts, ensuring that the verification task is completed within the expected time limit. The directed weighted graph composed of the verification capacity determined by the above multi-dimensional factors truly reflects the comprehensive verification capability of node credibility, cost rationality, and timeliness guarantee.

[0010] After obtaining the directed weighted graph for verification, a verification residual network is constructed, and the residual verification capacity of all verification edges is determined according to a breadth-first or depth-first traversal strategy. The bottleneck verification capacity for a single trusted execution node to individually verify the asset amount is calculated through multi-path parallel verification share allocation, or the bottleneck verification capacity of a combined path for multiple trusted execution nodes to jointly verify the asset amount. Based on this, the residual network is updated. When no more paths with allocable verification shares can be found, multiple parallel verification sub-paths are obtained. This parallel verification share allocation mechanism can divide the asset amount into multiple verification shares, which are then verified in parallel by different nodes along different sub-paths, greatly improving verification throughput and efficiency.

[0011] During the generation and confirmation of trusted verification results, the verification shares allocated to each parallel verification sub-path are aggregated. When the sum of the shares of all verification sub-paths reaches the asset amount, an intermediate state of verification success is generated. This intermediate state is then aggregated with the signatures of the corresponding nodes to form a verification proof data packet. In response to the verification client's confirmation operation on the displayed verification proof data packet, the verification proof data packet is submitted to the smart contract corresponding to the digital asset transfer request. The smart contract verifies the validity of the node signature aggregation, and executes the asset transfer operation after successful verification. Through multi-node signature aggregation and user confirmation, the traceability and non-repudiation of the verification results are guaranteed.

[0012] As a further improvement of this invention, after determining the trusted verification result, the historical verification reputation value of each node in the trusted execution node set is updated according to the ratio of the actual verification capacity consumed by each verification sub-path to the initially allocated verification capacity, and the updated reputation value is written into the reputation storage contract of the blockchain network. This forms a closed-loop reputation update mechanism, which dynamically reflects the historical performance of nodes in the allocation of subsequent verification tasks, continuously optimizing verification quality and overall system reliability.

[0013] This invention also provides a financial transaction verification system for trusted smart contracts, including a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the steps of the aforementioned financial transaction verification method for trusted smart contracts. This system integrates verification node evaluation, directed weighted graph construction, multi-path parallel allocation, and smart contract execution, enabling efficient and reliable verification and automatic execution of digital asset transfers in a decentralized environment.

[0014] The technical effects and advantages provided by the present invention in the above technical solution are as follows:

[0015] By using the financial transaction verification system as the coordination center, the set of trusted execution nodes as the verification source, and the digital asset transfer request as the verification endpoint, a directed weighted graph for verification is constructed. This abstracts the decentralized node verification capabilities into the verification capacity of each edge in the graph. When determining the verification capacity of each edge from the verification source to the coordination center, the dynamic verification trust factor, verification cost edge weight, and verification timeliness edge weight are considered. The dynamic verification trust factor is derived from the node's historical verification accuracy and response latency adjusted by a latency decay coefficient, rather than relying solely on static credit scores. This introduces a quantitative reflection of the volatility of node behavior into the graph's topology. The verification cost edge weight and verification timeliness edge weight are derived from the offset of the node's verification quote within the overall quote diameter, corrected by a cost weight decay coefficient, and the effect of the node's timeout decay rate on the difference between the promised and expected duration, respectively. This ensures that the capacity carried by each verification edge not only expresses the upper limit of the amount a node can bear but also includes the cost and timeliness of the source reaching the endpoint via the coordination center. The edge capacity formed by this multi-dimensional factor aggregation enables the directed weighted graph to accurately describe the verification feasibility and hidden risks of different paths, providing a measurable network foundation for splitting the verification load among multiple nodes.

[0016] Based on the verification capacity of each path edge in the directed weighted graph, multiple parallel verification sub-paths are determined through multi-path parallel verification share allocation. During this process, a verification residual network is constructed, and the bottleneck verification capacity of a single path or a combination of paths is calculated. This approach allows the asset amount to be divided into multiple verification shares according to the actual capacity of different paths. Multiple trusted execution nodes independently and in parallel complete the verification of their respective shares. Finally, when the sum of the verification shares reaches the asset amount, an intermediate state is generated and aggregated with node signatures to form a verification proof data packet. The use of parallel verification sub-paths breaks the rigid constraint of a single node's verification capability, avoiding dependence on the upper limit of a single node's capacity. The updating of the residual network and the round-by-round calculation of the bottleneck capacity ensure that the verification share is continuously allocated until saturation from a global perspective. The ebb and flow of verification capacity between paths are fully incorporated into the allocation decision. Thus, in an environment where untrusted nodes coexist, a parallelized and aggregatable verification structure achieves dynamic balancing of the verification load and fusion verification of verification results under large asset transfer requests. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0018] Figure 1 This is a flowchart of a financial transaction verification method using trusted smart contracts;

[0019] Figure 2 This is a flowchart for determining the set of trusted execution nodes based on the historical activity score of nodes;

[0020] Figure 3 This is a flowchart for verifying the construction of a directed weighted graph;

[0021] Figure 4 This is a flowchart illustrating the method for determining cost edge weights;

[0022] Figure 5 This is a distribution chart of the number of times and frequency of historical verification of candidate execution nodes.

[0023] Figure 6 It is the path finding and cumulative verification share change curve under the asset amount allocation. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] See Figure 1 This invention provides a method for verifying financial transactions using trusted smart contracts, applied to a financial transaction verification system. The method includes: in response to receiving a digital asset transfer request, determining a set of trusted execution nodes participating in the current financial transaction verification from a blockchain network based on the asset issuer and asset recipient identifiers carried in the digital asset transfer request; constructing a directed weighted graph for verification based on the asset amount carried in the digital asset transfer request and the historical verification reputation values ​​of each node in the set of trusted execution nodes, using the financial transaction verification system as a coordination center, the set of trusted execution nodes as verification source points, and the digital asset transfer request as a verification endpoint; determining multiple parallel verification sub-paths between the set of trusted execution nodes and the digital asset transfer request through a multi-path parallel verification share allocation method, based on the verification capacity of each edge in the verification path from the verification source point through the coordination center to the verification endpoint in the directed weighted graph; determining a trusted verification result for the digital asset transfer request based on the verification capacity in the multiple parallel verification sub-paths; and triggering the execution of the smart contract corresponding to the digital asset transfer request in response to a confirmation operation on the displayed trusted verification result.

[0026] Example 1

[0027] See Figure 2 In its implementation, the financial transaction verification system, upon receiving a digital asset transfer request, parses the request to obtain the asset issuer's identifier and the asset recipient's identifier. The system then calls the query interface of the smart contract registered by nodes in the blockchain network, passing in the asset issuer's identifier and the asset recipient's identifier, to obtain a list of all nodes that have historical transaction verification relationships with both the asset issuer and the asset recipient. A historical transaction verification relationship is defined as a node's participation in the verification process of a historical transaction between the asset issuer and the asset recipient, with the corresponding verification records stored on the blockchain. Through on-chain queries, the financial transaction verification system obtains a set of candidate execution nodes.

[0028] The historical verification delegation count and delegation frequency of each candidate execution node in the blockchain network are determined. In one implementation, the financial transaction verification system maintains a delegation statistics database off-chain. This database synchronizes data by monitoring newly generated blocks on the blockchain and parsing the delegation event logs within those blocks. The historical verification delegation count is defined as the cumulative total number of times a candidate execution node has been selected as a transaction verification executor within a preset historical time window. The preset historical time window can be set to look back a fixed number of blocks from the current block height, for example, 86,400 blocks. The length of the preset historical time window corresponding to 86,400 blocks is determined based on the average block interval of the blockchain network and the expected statistical duration, in order to capture recent and stable delegation behavior patterns. The delegation frequency is defined as the ratio of the historical verification delegation count of a candidate execution node within the preset historical time window to the total number of blocks in the preset historical time window. The financial transaction verification system queries the delegation statistics database to count the number of all delegation event records corresponding to each candidate execution node within a preset historical time window, thus obtaining the historical number of delegations. Then, it divides the historical number of delegations by the total number of blocks in the preset historical time window to obtain the delegation frequency.

[0029] Based on the historical number of times and frequency of delegation of verification for each candidate execution node in the blockchain network, the set of trusted execution nodes for financial transaction verification is dynamically determined. The financial transaction verification system calculates a historical activity score for each candidate execution node. The formula for calculating the historical activity score is as follows:

[0030]

[0031] in, Indicates candidate execution nodes The node's historical activity score; Indicates candidate execution nodes The number of times historical verification was delegated within the preset historical time window; Indicates candidate execution nodes The frequency of delegation within a preset historical time window; The frequency weighting coefficient, For frequency weighting coefficients, and The values ​​of all values ​​are between 0 and 1, and satisfy the following conditions: Frequency weighting coefficient With frequency weighting coefficient The specific value is determined based on the discrete characteristics of historical delegated data: when the variance of the number of delegated verifications in history is large, it indicates that the distribution of delegated verifications among candidate execution nodes is uneven, and the frequency weighting coefficient should be increased. To highlight the consistent nature of the entrusted frequency; when the variance of the entrusted frequency is large, the frequency weighting coefficient should be increased. In one optional setting, statistical analysis of a large number of historical commission records reveals that the coefficient of variation of the commission frequency is less than the coefficient of variation of the historical verification commission count, indicating that the commission frequency is more stable within the time window. Therefore, this setting is adopted. It is 0.4. The threshold is 0.6. After calculating the historical activity scores of all candidate execution nodes, the financial transaction verification system sorts them from highest to lowest based on these scores. The system uses a pre-defined mapping table to determine the number of nodes K to be selected based on the asset amount carried in the digital asset transfer request. The larger the asset amount, the larger the value of K, with a minimum value of 3, and K is always an odd number. The pre-defined mapping table stores the correspondence between asset amount ranges and K values. For example, K is 3 when the asset amount is between 100 and 1000 units, and 5 when it is between 1000 and 10000 units. This mapping relationship is set according to the system security level and parallel verification requirements. The financial transaction verification system selects the top K candidate execution nodes from the sorted list to form a trusted execution node set.

[0032] See Figure 5 In the graph, the horizontal axis represents the number of times a candidate execution node's historical verification was delegated within a preset historical time window, and the vertical axis represents the corresponding delegation frequency. Hollow circles represent candidate execution nodes (not selected), and solid diamonds represent trusted execution nodes (selected). The distribution in the graph shows a clear positive correlation between the number of historical verification delegations and the delegation frequency, indicating that the more times a node is delegated in historical verification, the higher its delegation frequency.

[0033] As described in Example 1, the financial transaction verification system determines the number of times a candidate execution node has been delegated for verification based on its historical verification history. With the frequency of the entrusted Compute node historical activity score After sorting nodes by activity score from highest to lowest, the number of candidate nodes is determined by combining the amount of assets carried in the digital asset transfer request. Finally, nodes were selected as the set of trusted execution nodes.

[0034] The solid diamond-shaped trusted execution nodes in the diagram are all located in areas where historical verification has been delegated more than approximately 120 times and the delegation frequency exceeds approximately 0.0015. This indicates that the system prioritizes nodes with high activity within the historical time window, ensuring that the trusted execution node set possesses strong historical verification activity and a stable delegation frequency. The unselected nodes among the candidate execution nodes are mainly distributed in areas with low historical verification delegation counts and frequencies, consistent with the principle of selecting nodes through activity scoring in the implementation embodiment.

[0035] Example 2

[0036] See Figure 3 In practical implementation, the financial transaction verification system obtains the historical verification accuracy and historical verification response latency of each trusted execution node from the set of trusted execution nodes. The historical verification accuracy is defined as the proportion of trusted execution nodes that correctly complete the verification task within the historical sliding time window, and the historical verification response latency is defined as the time consumed by a trusted execution node from receiving the verification request to submitting the verification result for each verification task within the historical sliding time window.

[0037] The financial transaction verification system dynamically determines the dynamic verification credibility factor of each trusted execution node based on its historical verification accuracy and historical verification response latency. The dynamic verification credibility factor is determined as follows: the system calculates the base accuracy of each trusted execution node based on the ratio of the number of correct verifications within a historical sliding time window to the total number of verifications. The historical sliding time window is set to a time range that traces back a fixed number of blocks from the current time. The value of the fixed number of blocks is calculated based on the average block interval of the blockchain network and the expected statistical period, which is set to 10,000 blocks. The number of correct verifications is the number of verification tasks in which the trusted execution node participated within the historical sliding time window, and whose verification results were confirmed by the blockchain network consensus without being challenged. The total number of verifications is the total number of verification tasks in which the trusted execution node participated within the historical sliding time window.

[0038] The financial transaction verification system determines the latency fluctuation deviation of each trusted execution node based on the difference between the response latency of each historical verification within a historical sliding time window and the average response latency of all historical verifications within the historical sliding time window. The average response latency of all historical verifications within the historical sliding time window is obtained by summing the response latency of all historical verifications of the trusted execution node within the historical sliding time window and dividing by the total number of verifications performed by that trusted execution node within the historical sliding time window.

[0039] The financial transaction verification system determines the latency decay coefficient for each trusted execution node based on the ratio of its latency fluctuation deviation to the maximum latency fluctuation deviation of all trusted execution nodes within a historical sliding time window, and a preset latency decay mapping relationship. The preset latency decay mapping relationship is stored as a segmented mapping table. The input to the segmented mapping table is the ratio of the latency fluctuation deviation to the maximum latency fluctuation deviation, and the output is the latency decay coefficient. The segmented mapping table is divided as follows: when the ratio is in the range [0, 0.3], the latency decay coefficient is 1.0; when the ratio is in the range (0.3, 0.6], the latency decay coefficient is 0.8; when the ratio is in the range (0.6, 0.8], the latency decay coefficient is 0.5; and when the ratio is in the range (0.8, 1.0], the latency decay coefficient is 0.2. The segmentation of the mapping table is based on the fact that the impact of response latency fluctuation on the reliability of verification timeliness exhibits a non-linear decay characteristic; the higher the deviation of the trusted execution node, the greater the decrease in the latency decay coefficient.

[0040] The financial transaction verification system determines the dynamic verification credibility factor of each trusted execution node based on the product of the basic accuracy and the latency attenuation coefficient of each trusted execution node.

[0041] The financial transaction verification system determines the verification cost edge weights from each verification source node to the coordination center in the directed weighted graph based on the verification quotes submitted by each trusted execution node in the trusted execution node set for digital asset transfer requests and the corresponding budgeted verification fees. The verification quote from a trusted execution node for a digital asset transfer request is the service fee amount submitted to the financial transaction verification system by the trusted execution node when responding to the verification request, required to complete the verification task. The budgeted verification fee is the maximum payable amount set by the initiator of the digital asset transfer request for this verification task. The verification cost edge weights are determined by using the ratio of the trusted execution node's verification quote to the budgeted verification fee as input, and mapping it through a preset cost mapping function. The preset cost mapping function is either a monotonically increasing linear function or a piecewise function.

[0042] The financial transaction verification system determines the verification timeliness edge weights from each verification source node to the coordination center in the directed weighted graph based on the committed verification completion time of each trusted execution node in the trusted execution node set for a digital asset transfer request, the historical number of verification timeouts for each trusted execution node, and the expected verification completion time for the digital asset transfer request. The committed verification completion time is the time from receiving verification data to submitting the verification result that a trusted execution node promises when responding to a verification request. The expected verification completion time is the upper limit of the expected verification task completion time set by the initiator of the digital asset transfer request. The historical number of verification timeouts is the number of times a trusted execution node submits a verification result exceeding the committed verification completion time within a historical sliding time window.

[0043] The financial transaction verification system determines the verification capacity of the edges from the verification source node to the coordination center in the directed weighted graph of verification based on the dynamic verification credibility factor, verification cost edge weight, verification timeliness edge weight of each trusted execution node in each trusted execution node set, and the product of the smaller of the historical verification reputation value and the asset amount corresponding to each trusted execution node. The formula for calculating the verification capacity is as follows:

[0044]

[0045] in, Indicates verification source point To the coordination center The verification capacity of the edges; Indicates verification source point The corresponding trusted execution node's dynamic verification trust factor ranges from 0 to 1; Indicates verification source point The verification cost edge weight of the corresponding trusted execution node; Indicates verification source point The verification time edge weight of the corresponding trusted execution node; Indicates verification source point The historical verified reputation value of the corresponding trusted execution node is a value stored in the reputation storage contract of the blockchain network; Indicates the amount of assets carried in the digital asset transfer request; This indicates that the smaller of the historical verified credit score and the asset amount should be taken; This represents the reciprocal of the edge weight of the verification cost; This represents the reciprocal of the edge weight for verification time.

[0046] The financial transaction verification system determines the verification capacity of the edges from the verification endpoint to the coordination center in the directed weighted graph based on the asset amount carried in the digital asset transfer request. The verification capacity of the edges from the verification endpoint to the coordination center is set to the asset amount. The system constructs the directed weighted graph based on the verification capacities of the edges from the verification source nodes to the coordination center and the edges from the verification endpoints to the coordination center for each set of trusted execution nodes in the graph. The directed weighted graph is stored in the system's memory as an adjacency matrix or adjacency list. The nodes in the graph include the set of verification source nodes, the coordination center node, and the verification endpoint node. The edges include directed edges from each verification source node to the coordination center node and directed edges from each verification endpoint node to the coordination center node. Each directed edge is associated with a verification capacity attribute.

[0047] Example 3

[0048] See Figure 4 In its implementation, the financial transaction verification system acquires verification quotes submitted by each trusted execution node in the set of trusted execution nodes for digital asset transfer requests. The system identifies the highest and lowest verification quotes from all acquired quotes. It then calculates a first quote difference between the highest and lowest quotes, defining this first quote difference as the verification quote diameter. The verification quote diameter characterizes the distribution span of verification quotes within the set of trusted execution nodes.

[0049] The financial transaction verification system determines a weighted average verification quote based on the verification quotes from each trusted execution node for a digital asset transfer request and the time decay offset of each verification quote from the current time. The time decay offset of each verification quote from the current time is defined as the absolute value of the time difference between the verification quote's submission timestamp and the current system timestamp, in milliseconds.

[0050] The weighted average verified quote is determined as follows: The financial transaction verification system obtains the preset verified quote volatility and the mean and standard deviation of the verified quotes corresponding to each trusted execution node within a preset historical time period from the current time. The preset verified quote volatility is stored in the configuration parameters of the financial transaction verification system. The preset verified quote volatility is set based on the historical quote volatility statistics of similar verification services on the blockchain network, and the preset verified quote volatility is set to 0.15. The preset historical time period is set to 7,200,000 milliseconds backward from the current system time. The financial transaction verification system queries the local quote history database for all historical verified quote records of each trusted execution node within the preset historical time period, and calculates the mean and standard deviation of the historical verified quotes of each trusted execution node within the preset historical time period.

[0051] The financial transaction verification system determines the adaptive verification price volatility based on the mean and standard deviation of historical verification quotes for each trusted execution node over a preset historical period. The adaptive verification price volatility is obtained by dividing the standard deviation of historical verification quotes for each trusted execution node by its mean historical verification quotes to obtain the historical price volatility coefficient for each trusted execution node. Then, the mean of all historical price volatility coefficients of trusted execution nodes is taken, and a weighted average is calculated with the preset verification price volatility to obtain the adaptive verification price volatility. The weighting of the average is configured as follows: the preset verification price volatility has a weight of 0.3, and the mean of historical price volatility coefficients has a weight of 0.7.

[0052] The financial transaction verification system determines the quote time decay weight for each trusted execution node based on the quote time decay offset from the current time and the adaptive verification quote volatility. The quote time decay weight is calculated as follows: using the natural constant e as the base, the negative of the product of the adaptive verification quote volatility and the quote time decay offset is used as the exponent; then, e is raised to the power of this exponent, and the result is the quote time decay weight.

[0053] The financial transaction verification system determines the weighted attenuation verification price for each trusted execution node by multiplying the price's time decay weight by the verification price of the corresponding digital asset transfer request. The system then sums the weighted attenuation verification prices for all trusted execution nodes to determine the total weighted attenuation verification price. Finally, the system calculates the ratio of the total weighted attenuation verification price to the total price's time decay weight, and uses this ratio as the weighted average verification price.

[0054] The financial transaction verification system determines the verification quote offset for each trusted execution node based on the absolute value of the second quote difference between the verification quote of each trusted execution node for a digital asset transfer request and the weighted average verification quote. The second quote difference is defined as the difference between the verification quote of the trusted execution node and the weighted average verification quote.

[0055] The financial transaction verification system determines the verification cost edge weights from each verification source point to the coordination center in the directed weighted graph based on the ratio between the verification quote offset and the verification quote diameter for each trusted execution node, and the cost weight decay coefficient corresponding to the preset deviation threshold range of the ratio. The system calculates the ratio of the verification quote offset to the verification quote diameter for each trusted execution node and matches this ratio with a preset deviation threshold range. The preset deviation threshold range includes low, medium, and high deviation ranges. The low deviation range is set to a ratio interval of [0, 0.25], the medium deviation range to a ratio interval of (0.25, 0.65], and the high deviation range to a ratio interval of (0.65, 1.0). The cost weight decay coefficient corresponding to the low deviation range is set to 0.9, the medium deviation range to 0.55, and the high deviation range to 0.2. The cost weight decay coefficient corresponding to the low deviation range is greater than that corresponding to the medium deviation range, and the medium deviation range is greater than that corresponding to the high deviation range. The specific value of the cost weight decay coefficient is based on the following: the closer the verification quote is to the trusted execution node of the weighted average verification quote, the stronger its quote rationality and market competitiveness are considered, and a higher verification cost edge weight should be given to increase its participation opportunity in the verification task. Therefore, the cost weight decay coefficient is kept at a high level in the low deviation range; the further the verification quote deviates from the weighted average verification quote of the trusted execution node, the more unstable or speculative its quote may be. Its competitive advantage in verification capacity allocation should be reduced by quickly lowering the cost weight decay coefficient.

[0056] The financial transaction verification system determines the cost weight decay coefficient matched to each trusted execution node as the verification cost edge weight from the corresponding verification source point to the coordination center in the directed weighted graph of verification. The verification cost edge weight is used to adjust the cost dimension impact of trusted execution nodes in the verification capacity calculation. The larger the verification cost edge weight, the stronger the bidding competitiveness of the trusted execution node.

[0057] Example 4

[0058] In practical implementation, the financial transaction verification system obtains the historical timeout verification count and the historical total verification count for each trusted execution node in the trusted execution node set. The historical timeout verification count is defined as the number of verification tasks completed by a trusted execution node within a historical sliding time window, where the actual verification completion time exceeds the promised completion time for that task. The historical total verification count is defined as the total number of verification tasks a trusted execution node participates in within a historical sliding time window. The historical sliding time window is set consistently with the historical sliding time window used in the aforementioned embodiment for determining the dynamic verification trust factor; both involve a fixed number of blocks traced back from the current time point. The value of the fixed number of blocks is calculated based on the average block interval of the blockchain network and the expected statistical period, which is set to 10,000 blocks.

[0059] The financial transaction verification system determines the timeout decay rate for each trusted execution node based on the ratio of the historical timeout verification count to the total historical verification count. The timeout decay rate characterizes the reliability of the trusted execution node in adhering to its promised verification completion time in historical verifications.

[0060] The financial transaction verification system obtains the committed verification completion time submitted by each trusted execution node for a digital asset transfer request, as well as the expected verification completion time carried in the digital asset transfer request. The committed verification completion time is the length of time, in milliseconds, that the trusted execution node declares to the financial transaction verification system when receiving the verification task, indicating its anticipated completion of the verification and submission of the verification result. The expected verification completion time is the maximum allowed time for the verification task to complete, set by the initiator of the digital asset transfer request.

[0061] The financial transaction verification system calculates the time difference between the promised verification completion time and the expected verification completion time for each trusted execution node. This time difference is the absolute value of the difference between the promised and expected verification completion times. Based on the timeout decay rate for each trusted execution node and the time difference for that node, the system determines the verification timeliness edge weights from each verification source node to the coordination center in the directed weighted graph. The formula for calculating the verification timeliness edge weights is as follows:

[0062]

[0063] in, Indicates verification source point To the coordination center Verification timeliness edge weight; Indicates verification source point The corresponding timeout decay rate of the trusted execution node. The value ranges from 0 to 1, and is obtained by dividing the number of historical timeout verifications of the trusted execution node within the historical sliding time window by the total number of historical verifications. Indicates verification source point The corresponding trusted execution node's commitment verification completion time for digital asset transfer requests, in milliseconds; This indicates the expected verification completion time for a digital asset transfer request, in milliseconds. This represents the absolute value of the difference between the promised verification completion time and the expected verification completion time.

[0064] In one implementation, the time-sensitive edge weights are verified. The larger the value, the worse the trusted execution node performs in terms of timeliness, and the stronger the reduction effect on verification capacity in subsequent verification capacity calculations.

[0065] The financial transaction verification system is based on a constructed directed weighted graph of verification. According to the verification capacity of each edge in the verification path from each verification source point to the verification endpoint through the coordination center, the system determines multiple parallel verification sub-paths between the set of trusted execution nodes and the digital asset transfer request through a multi-path parallel verification share allocation method.

[0066] The process of determining multiple parallel verification sub-paths is as follows: The financial transaction verification system constructs a verification residual network based on each verification path from the verification source point through the coordination center to the verification endpoint in the verification directed weighted graph. The node set of the verification residual network is the same as that of the verification directed weighted graph. In the verification residual network, for each directed edge from the verification source point to the coordination center and from the verification endpoint to the coordination center in the verification directed weighted graph, a forward edge and a reverse edge are constructed. The residual verification capacity of the forward edge is initialized to the verification capacity of that directed edge in the verification directed weighted graph, and the residual verification capacity of the reverse edge is initialized to zero.

[0067] The financial transaction verification system employs either a breadth-first search (BFS) or depth-first search (DFS) strategy on the verification residual network to find a verification share allocation path starting from any verification source node, passing through the coordination center, and reaching the verification endpoint. The choice between BFS and DFS is determined by the financial transaction verification system based on the size of the verification residual network. A DFS strategy is used when the number of verification source nodes is less than a preset threshold of 50, and a BFS strategy is used when the number of verification source nodes is greater than or equal to the preset threshold of 50. During the traversal, the financial transaction verification system records the residual verification capacity corresponding to each verification edge on the path and determines the bottleneck verification capacity of the path as the minimum residual verification capacity of all verification edges on the path.

[0068] The financial transaction verification system calculates the bottleneck verification capacity of either a single path where a trusted execution node individually verifies the asset amount, or a combined path where multiple trusted execution nodes jointly verify the asset amount, based on the verification capacity of each edge in the verification path from the verification source node through the coordination center to the verification endpoint in the directed weighted graph of verification. This is achieved through a multi-path parallel verification share allocation method. A single path is defined as a path containing only one verification source node, while a combined path is defined as a set of paths containing at least two different verification source nodes.

[0069] The financial transaction verification system determines the allocated verification share for each single path or combination of paths it finds. Based on the bottleneck verification capacity of each single path and combination of paths, the system updates the residual verification capacity of all verification edges in the verification residual network. The update method is as follows: for each forward edge on the path, subtract the bottleneck verification capacity from its residual verification capacity; for each reverse edge on the path, add the bottleneck verification capacity to its residual verification capacity.

[0070] The financial transaction verification system repeatedly executes pathfinding and residual verification capacity update processes until the sum of all allocated verification shares reaches the asset amount carried in the digital asset transfer request, or until no path with a remaining verification capacity greater than zero can be found in the verification residual network from the verification source point through the coordination center to the verification endpoint. If pathfinding for verification share allocation can no longer be performed in the verification residual network, the financial transaction verification system obtains multiple single paths and combined paths found in the prior search process.

[0071] The financial transaction verification system determines multiple parallel verification sub-paths between the set of trusted execution nodes and the digital asset transfer request, based on the obtained single and combined paths. Each parallel verification sub-path corresponds to a component path in a single or combined path, and each parallel verification sub-path is assigned a verification share. The sum of the verification shares of all parallel verification sub-paths should reach the asset amount.

[0072] See Figure 6 In the graph, the horizontal axis represents the number of pathfinding iterations, and the vertical axis represents the cumulative verification share, in units of asset value. The solid curve in the graph shows the trend of the cumulative verification share as the number of pathfinding iterations increases; the dashed horizontal line represents the asset value carried in the digital asset transfer request, which is constant at 10,000 units.

[0073] As shown in the graph, the cumulative verification share grows rapidly in the early stages of path finding, approximately between iterations 0 and 50. The cumulative verification share quickly rises from near zero to approximately 7000 units, indicating that the financial transaction verification system rapidly allocates the verification share for most assets through the continuous search of multiple parallel verification sub-paths and the allocation of verification capacity. Subsequently, during the path finding process of approximately 50 to 75 iterations, the cumulative verification share continues to grow slowly, gradually approaching the asset amount of 10,000 units.

[0074] When the pathfinding iterations approach 75, the cumulative verification share reaches and stabilizes at an asset value of 10,000 units, indicating that the verification requirements for the asset value carried in the digital asset transfer request have been fully met, and the overall verification capacity allocation is complete. In subsequent iterations (approximately 75 to 200), the cumulative verification share remains stable, indicating that the financial transaction verification system stops allocating new verification capacity, and the verification task enters the intermediate stage of verification success.

[0075] This figure illustrates the process described in Example 4, which involves constructing a verification residual network based on a directed weighted graph and allocating verification shares through multiple paths in parallel using a breadth-first or depth-first strategy. By continuously searching for single or combined paths and dynamically updating the residual capacity, the cumulative verification share reaches the asset amount specified in the digital asset transfer request, ensuring the complete allocation and efficient completion of the verification task. The two-stage growth trend of the curve reflects the efficiency of path finding and the gradual saturation of verification capacity. The verification process achieves precise matching of asset amounts and reasonable allocation of verification resources.

[0076] Example 5

[0077] In practice, the financial transaction verification system extracts the verification share corresponding to each of the multiple parallel verification sub-paths, and accumulates the verification shares of all parallel verification sub-paths to obtain a total accumulated verification share. The financial transaction verification system compares the total accumulated verification share with the asset amount carried in the digital asset transfer request. When the total accumulated verification share equals the asset amount carried in the digital asset transfer request, the financial transaction verification system determines that the asset amount has been fully allocated for verification and generates an intermediate state of verification success. The intermediate state of verification success includes the following fields: the request identifier of the digital asset transfer request, the asset issuer identifier, the asset recipient identifier, the asset amount, the path identifier and corresponding verification share of each parallel verification sub-path, and the timestamp of the intermediate state generation.

[0078] The financial transaction verification system obtains the node signatures of trusted execution nodes corresponding to each of the multiple parallel verification sub-paths. A node signature is a byte sequence obtained by the trusted execution node using its blockchain account private key to sign the hash value of the verified intermediate state using an elliptic curve digital signature algorithm. The financial transaction verification system aggregates the verified intermediate state with the node signatures of all relevant trusted execution nodes to generate a verification proof data packet. The aggregation method uses a signature aggregation data structure, taking the verified intermediate state as the payload, arranging all node signatures according to the registration order of the trusted execution nodes in the blockchain network to form a signature list, and packaging it with the payload into a verification proof data packet.

[0079] The financial transaction verification system pushes the verification certificate data package to the display interface of the verifier's client. The verifier's client is the terminal application used by the initiator or recipient of the digital asset transfer request. The display interface shows key information of the intermediate state after successful verification, as well as a list of trusted execution nodes participating in the verification and the digest values ​​of the node signatures. The financial transaction verification system listens for confirmation operations from the verifier's client regarding the displayed verification certificate data package. A confirmation operation is either the verifier's client's signature approval of the verification certificate data package or a trigger event of the confirmation button on the interface. In response to a detected confirmation operation, the financial transaction verification system submits the verification certificate data package to the smart contract corresponding to the digital asset transfer request through the blockchain network's transaction submission interface. The smart contract corresponding to the digital asset transfer request is executable code pre-deployed on the blockchain network, containing asset transfer logic. The contract address of the smart contract is specified by the contract address field carried in the digital asset transfer request.

[0080] Upon receiving the verification data packet, the smart contract triggers a verification process to validate the validity of the node signature aggregation within the data packet. The verification process is as follows: the smart contract extracts the verified intermediate states and signature list from the verification data packet, calculates the hash value of the verified intermediate states, signs each node in the signature list, and verifies the signature using the public key corresponding to that node using the elliptic curve digital signature algorithm. The public key is retrieved from the node registration smart contracts on the blockchain network. The smart contract verifies that all node signatures must be true, and the signer's node identifier must belong to the trusted execution node set. The list of identifiers for the trusted execution node set is appended to the transaction input data by the financial transaction verification system when submitting the verification data packet. After successful verification, the smart contract executes the asset transfer operation corresponding to the digital asset transfer request. The asset transfer operation involves calling the transfer function of the token smart contract to transfer digital assets of equal value from the asset issuer's account to the asset recipient's account.

[0081] If the verification fails, the smart contract rolls back the asset transfer operation and returns a verification failure event to the financial transaction verification system. The financial transaction verification system records the verification failure event and terminates the current verification process.

[0082] After successful verification, the financial transaction verification system updates the historical verification reputation value of each trusted execution node in the trusted execution node set based on the ratio of the actual verification capacity consumed by each verification sub-path to the initial verification capacity allocated to each sub-path. The actual verification capacity consumed by each sub-path is defined as the amount of verification computing resources actually used during the verification process, and is reported by the trusted execution node when submitting the verification results. The initial verification capacity allocated to each sub-path is the verification capacity value assigned to that sub-path when constructing the directed weighted graph of verification and allocating parallel verification sub-paths.

[0083] The formula for calculating the historical verification reputation value of each trusted execution node in the updated trusted execution node set is as follows:

[0084]

[0085] in, Indicates a trusted execution node Updated historical verification reputation value; Indicates a trusted execution node The historical verified reputation value before the update is read from the reputation storage contract of the blockchain network; Indicates a trusted execution node The sum of the actual verification capacity consumed in all parallel verification subpaths; Indicates a trusted execution node The sum of the initially allocated verification capacities across all parallel verification subpaths; Adjust the step size coefficient for reputation. The value ranges from 0 to 1, and is specifically set to 0.05. Credit adjustment step size coefficient. The setting of 0.05 is based on the trade-off between the convergence speed and stability of the reputation value in multiple simulation tests. When the value is too large, the reputation score fluctuates drastically after a single verification. When the value is too small, the reputation value updates slowly. Test results show that 0.05 can make the reputation value converge to a stable range within about 20 verification cycles, while avoiding large jumps in the reputation value caused by a single abnormal verification.

[0086] After calculating the updated historical verification reputation value for each trusted execution node, the financial transaction verification system calls the update interface of the blockchain network's reputation storage contract to write the updated historical verification reputation value into the contract's storage space. The reputation storage contract maintains a mapping table from trusted execution node identifiers to historical verification reputation values. The update interface uses the trusted execution node identifier as the key to... Store the corresponding value in the mapping table.

[0087] A trusted smart contract financial transaction verification system includes a memory, a processor, and a computer program stored in the memory and running on the processor. The memory is a random access memory or a non-volatile storage medium, and the processor is a central processing unit or a dedicated processor for blockchain verification nodes. When the processor executes the computer program, it loads all the steps of the aforementioned trusted smart contract financial transaction verification method, including responding to a received digital asset transfer request, determining a set of trusted execution nodes, constructing a directed weighted graph for verification, determining multiple parallel verification sub-paths, determining the trusted verification result and triggering smart contract execution, and updating historical verification reputation values. The financial transaction verification system interacts with other nodes in the blockchain network through a communication module, which supports Transmission Control Protocol (TCP) and blockchain peer-to-peer network protocols.

[0088] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for verifying financial transactions using trusted smart contracts, characterized in that, The method, applied to a financial transaction verification system, includes: In response to receiving a digital asset transfer request, based on the asset issuer identifier and asset recipient identifier carried in the digital asset transfer request, a set of trusted execution nodes participating in the verification of the current financial transaction is determined from the blockchain network. Based on the amount of assets carried in the digital asset transfer request and the historical verification reputation value of each node in each set of trusted execution nodes, a directed weighted graph for verification is constructed, with the financial transaction verification system as the coordination center, the set of trusted execution nodes as the verification source point, and the digital asset transfer request as the verification endpoint. Based on the verification capacity of each edge in the verification path from the verification source point to the verification endpoint through the coordination center in the verification directed weighted graph, multiple parallel verification sub-paths between the trusted execution node set and the digital asset transfer request are determined by the method of multi-path parallel verification share allocation. Based on the verification capacity in the multiple parallel verification sub-paths, a reliable verification result for the digital asset transfer request is determined, and in response to the confirmation operation of the displayed reliable verification result, the execution of the smart contract corresponding to the digital asset transfer request is triggered.

2. The financial transaction verification method for a trusted smart contract according to claim 1, characterized in that, In response to receiving a digital asset transfer request, based on the asset issuer identifier and asset recipient identifier carried in the digital asset transfer request, a set of trusted execution nodes participating in the verification of the current financial transaction is determined from the blockchain network, including: In response to receiving a digital asset transfer request, based on the asset issuer identifier and asset recipient identifier carried in the digital asset transfer request, query candidate execution nodes that are registered in the blockchain network and have historical transaction verification relationships with both the asset issuer and the asset recipient. Determine the number of times and frequency of historical verification delegated to each candidate execution node in the blockchain network; Based on the number of times and frequency of historical verification delegated by each candidate execution node in the blockchain network, a set of trusted execution nodes for financial transaction verification is dynamically determined from the candidate execution nodes that have historical transaction verification relationships with both the asset issuer and the asset recipient.

3. The financial transaction verification method for a trusted smart contract according to claim 1, characterized in that, Based on the asset amount carried in the digital asset transfer request and the historical verification reputation value of each node in the set of trusted execution nodes, a directed weighted graph for verification is constructed, using the financial transaction verification system as the coordination center, the set of trusted execution nodes as the verification source, and the digital asset transfer request as the verification endpoint. This graph includes: Based on the historical verification accuracy and historical verification response latency of each node in each set of trusted execution nodes, the dynamic verification trust factor of each node is dynamically determined. Based on the verification quotes of each node in the trusted execution node set for the digital asset transfer request and the budgeted verification cost corresponding to the digital asset transfer request, the verification cost edge weights from each verification source point to the coordination center in the directed weighted graph of verification are determined. Based on the commitment verification completion time of each node in the trusted execution node set for the digital asset transfer request, the historical timeout verification count of the node, and the expected verification completion time of the digital asset transfer request, the verification timeliness edge weights from each verification source point to the coordination center in the directed weighted graph of verification are determined. Based on the dynamic verification trust factor of each node in each set of trusted execution nodes, the verification cost edge weight, the verification timeliness edge weight, and the product of the smaller value between the historical verification reputation value and the asset amount corresponding to each node, the verification capacity of the edge from the verification source point to the coordination center in the directed weighted graph of verification is determined. Based on the amount of assets carried in the digital asset transfer request, the verification capacity of the edge from the verification endpoint to the coordination center in the verification directed weighted graph is determined, and the verification directed weighted graph is constructed based on the verification capacity of the edge from the verification source point to the coordination center and the verification capacity of the edge from the verification endpoint to the coordination center corresponding to each set of trusted execution nodes in the verification directed weighted graph.

4. The financial transaction verification method for a trusted smart contract according to claim 3, characterized in that, Based on the historical verification accuracy and historical verification response latency of each node in each set of trusted execution nodes, a dynamic verification trust factor for each node is dynamically determined, including: The basic accuracy of each node is determined based on the ratio of the number of correct verifications to the total number of verifications for each node in the set of trusted execution nodes within the historical sliding time window. The latency fluctuation deviation value of each node is determined based on the difference between the response latency of each historical verification within the historical sliding time window and the average response latency of all historical verifications within the historical sliding time window. The delay attenuation coefficient of each node is determined based on the ratio of the delay fluctuation deviation of each node to the maximum delay fluctuation deviation of all nodes within the historical sliding time window, and the preset delay attenuation mapping relationship. The dynamic verification confidence factor of each node is determined by multiplying the base accuracy of each node by the delay attenuation coefficient.

5. The financial transaction verification method for a trusted smart contract according to claim 3, characterized in that, Based on the verification quotes from each node in the trusted execution node set for the digital asset transfer request and the budgeted verification cost corresponding to the digital asset transfer request, the verification cost edge weights from each verification source node to the coordination center in the directed weighted graph of verification are determined, including: The verification quote diameter is determined based on the first quote difference between the highest and lowest verification quotes among the verification quotes submitted by each node in the trusted execution node set for the digital asset transfer request. The weighted average verification quote is determined based on the verification quotes of each node for the digital asset transfer request and the time decay offset of each verification quote from the current time. The verification quote offset for each node is determined based on the absolute value of the second quote difference between the verification quote of each node for the digital asset transfer request and the weighted average verification quote. Based on the ratio between the verification quote offset corresponding to each node and the verification quote diameter, and the cost weight decay coefficient corresponding to the preset deviation threshold range in which the ratio is located, the verification cost edge weight from each verification source point to the coordination center in the directed weighted graph of verification is determined, wherein each preset deviation threshold range is correspondingly set with the cost weight decay coefficient.

6. The financial transaction verification method for trusted smart contracts according to claim 5, characterized in that, The preset deviation threshold range includes a low deviation range, a medium deviation range, and a high deviation range. The cost weight attenuation coefficient corresponding to the low deviation range is greater than the cost weight attenuation coefficient corresponding to the medium deviation range, and the cost weight attenuation coefficient corresponding to the medium deviation range is greater than the cost weight attenuation coefficient corresponding to the high deviation range.

7. The financial transaction verification method for a trusted smart contract according to claim 5, characterized in that, A weighted average verification quote is determined based on the verification quotes from each node for the digital asset transfer request and the time decay offset of each verification quote from the current time, including: An adaptive verification price volatility is determined based on the preset verification price volatility and the mean and standard deviation of the verification prices corresponding to each node within a preset historical time period from the current time. The time decay weight of each node is determined based on the time decay offset of the verification quote from the current time and the adaptive verification quote volatility. The weighted decay verification price for each node is determined by multiplying the price decay weight corresponding to the node's price by the verification price of the corresponding digital asset transfer request. Based on the weighted attenuation verification quotes corresponding to each node, the total weighted attenuation verification quotes are summed to determine the total quote time attenuation weights, and based on the quote time attenuation weights corresponding to each node, the total quote time attenuation weights are summed to determine the total quote time attenuation weights. The weighted average verification price is determined based on the ratio of the sum of the weighted attenuation verification prices to the sum of the price time attenuation weights.

8. The financial transaction verification method for a trusted smart contract according to claim 3, characterized in that, Based on the committed verification completion time of each node in the trusted execution node set for the digital asset transfer request, the historical timeout verification count of the corresponding node, and the expected verification completion time for the digital asset transfer request, the verification timeliness edge weights from each verification source node to the coordination center in the directed weighted graph of verification are determined, including: The timeout decay rate for each node is determined based on the ratio of the historical timeout verification count to the total historical verification count for each node in the trusted execution node set. Based on the timeout decay rate corresponding to each node and the time difference between the promised verification completion time of each node for the digital asset transfer request and the expected verification completion time corresponding to the digital asset transfer request, the verification timeliness edge weights from each verification source point to the coordination center in the directed weighted graph of verification are determined.

9. The financial transaction verification method for a trusted smart contract according to claim 1, characterized in that, Based on the verification capacity of each edge in the verification path from the verification source point to the verification endpoint via the coordination center in the directed weighted graph of verification, multiple parallel verification sub-paths between the trusted execution node set and the digital asset transfer request are determined through a multi-path parallel verification share allocation method, including: Based on each verification path from the verification source point to the verification endpoint via the coordination center in the verification directed weighted graph, a verification residual network is constructed. The residual verification capacity of all verification edges in the verification residual network is determined according to the breadth-first traversal strategy or the depth-first traversal strategy. Based on the verification capacity of each edge in the verification path from the verification source point through the coordination center to the verification endpoint in the verification directed weighted graph, the bottleneck verification capacity of a single path for a trusted execution node to individually verify and satisfy the asset amount, or the bottleneck verification capacity of a combined path for multiple trusted execution nodes to jointly verify and satisfy the asset amount is calculated through a multi-path parallel verification share allocation method. Based on the bottleneck verification capacity of each single path and each combined path, update the residual verification capacity of all verification edges in the verification residual network. If it is no longer possible to perform verification share allocation path finding in the verification residual network, obtain multiple single paths and combined paths. Based on the multiple single paths and the combined paths, the set of trusted execution nodes is determined to have multiple parallel verification sub-paths between the coordination center and the digital asset transfer request.

10. A financial transaction verification system for trusted smart contracts, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the financial transaction verification method for a trusted smart contract as described in any one of claims 1 to 9.

Images