Path determination method, device and equipment

Abstract

The invention discloses a path determination method, device and equipment, and relates to the technical field of blockchains, and the method comprises the steps: determining a plurality of candidate transaction paths and a path attribute corresponding to each candidate transaction path according to a transaction parameter in a transaction request in response to a decentralized transaction request; compared with the prior art, the method does not depend on manual rules to judge the advantages and disadvantages of the paths, but obtains the on-chain and off-chain real-time transaction environment characteristics for each candidate transaction path, and outputs the model evaluation result through the preset path evaluation model according to the real-time transaction environment characteristics and the path attributes, and the model evaluation result comprises the estimation of the number of account tokens and the path execution success rate. And calculating a comprehensive score of each candidate transaction path according to the pre-estimated account token number and the path execution success rate, and screening from the candidate transaction paths according to the comprehensive scores to obtain a target transaction path. The technical problem that an execution path cannot be accurately selected by adopting routing logic driven by a fixed rule in a complex or rapidly changing execution environment can be solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchain, and particularly relates to a path determination method, device and equipment. BACKGROUND

[0002] In a decentralized exchange (DEX), the same trading pair is usually distributed in hundreds of independent liquidity pools. These liquidity pools each have different reserve ratios, fee parameters and on-chain states, and dynamically change with block updates. To achieve efficient token exchange, the industry introduces an aggregator router, the core function of which is to automatically traverse all possible trading paths, including cross-pool, cross-protocol and even cross-chain paths, through a routing algorithm to determine the optimal execution path that maximizes the target token output or minimizes resource consumption.

[0003] Currently, mainstream aggregator routers use routing logic driven by fixed rules. For example, the routing strategy may prioritize pools with larger reserves or exclude pools with fees higher than a threshold. The weight configuration of such rules relies on manual adjustment, and the update mechanism usually pushes parameter changes gradually through a gray release method. In a complex or rapidly changing execution environment, routing logic driven by fixed rules cannot accurately select the execution path. SUMMARY

[0004] The main purpose of the present application is to provide a path determination method, device and equipment, aiming to solve the technical problem that routing logic driven by fixed rules cannot accurately select the execution path in a complex or rapidly changing execution environment.

[0005] To achieve the above-mentioned purpose, the present application provides a path determination method, which comprises: In response to a decentralized transaction request, a plurality of candidate transaction paths and path attributes corresponding to each candidate transaction path are determined according to transaction parameters in the transaction request; For each candidate transaction path, real-time transaction environment features on and off the chain are obtained, and a model evaluation result is output through a preset path evaluation model according to the real-time transaction environment features and the path attributes, the model evaluation result comprising an estimated token amount and a path execution success rate, wherein the preset path evaluation model is obtained by training a preset sparse hybrid expert network based on decentralized transaction samples; According to the estimated token amount and the path execution success rate, a comprehensive score of each candidate transaction path is calculated; According to the comprehensive score, a target transaction path is selected from the candidate transaction paths.

[0006] In one embodiment, the step of outputting a model evaluation result based on the real-time trading environment characteristics and the path attributes using a preset path evaluation model includes: Scan the public memory pool and private transaction pool in the blockchain network to identify unprocessed transactions in the public memory pool and private transaction pool whose transaction direction is the same as the transaction request; Extract MEV risk characteristics from the pending transactions; Based on the MEV risk characteristics, real-time trading environment characteristics, and path attributes, the model evaluation results are output through a preset path evaluation model.

[0007] In one embodiment, the step of calculating the comprehensive score of each candidate transaction path based on the estimated number of tokens to be received and the path execution success rate includes: Determine the failure risk weight based on the success rate of the path execution; The risk penalty value is calculated based on the failure risk weight and the preset risk penalty coefficient, wherein the preset risk penalty coefficient is used to characterize the equivalent failure cost, and the equivalent failure cost is determined based on the failure cost knowledge learned by the preset reinforcement learning model. The overall score for each candidate transaction path is calculated based on the estimated number of tokens to be credited and the risk penalty value.

[0008] In one embodiment, after the step of filtering the candidate transaction paths from the candidate transaction paths based on the comprehensive score, the method further includes: After completing the on-chain execution, the actual execution result of the target transaction path is obtained, wherein the actual execution result includes the actual number of tokens received, the actual gas consumption cost, and the maximum extractable value (MEV) loss. The reward value is calculated based on the actual execution results and the estimated number of tokens received. The real-time transaction environment features are used as state features, the target transaction path is used as an action, and a decentralized transaction sample is constructed based on the state features, actions, and reward value. The decentralized transaction sample is then written into a message queue. Multiple historical transaction samples are continuously pulled from the message queue in real time to form a training batch; The state features in the training batch are input into the preset path evaluation model to obtain strategy output and value output, wherein the strategy output is the selection probability distribution of each candidate transaction path, and the value output is the expected cumulative return estimate for the selected action. Calculate the deep Q-network loss based on the reward value and the value output, and calculate the policy gradient loss based on the reward value and the value output. Based on the deep Q-network loss, the policy gradient loss, and the preset loss weights, the gradient is calculated through backpropagation, and the parameters are updated only on the low-rank adaptation matrix embedded in the preset path evaluation model to update the path evaluation model.

[0009] In one embodiment, the step of determining multiple candidate transaction paths based on transaction parameters in the transaction request includes: The transaction parameters in the transaction request are standardized and encapsulated to obtain the order message; Obtain real-time transaction status data of all transaction pools related to the order message from the blockchain; A directed weighted graph is constructed based on the transaction status data, wherein the nodes of the directed weighted graph are different tokens, the edges are transaction pools connecting two tokens, and the weight of the edges is determined based on the transaction fee cost and the estimated gas consumption. Based on the directed weighted graph and preset constraints, multiple candidate transaction paths are obtained by searching through a preset shortest path model. The preset constraints include at least a preset maximum number of hops, single pool depth, and cumulative transaction fees.

[0010] In one embodiment, the step of selecting the target transaction path from the candidate transaction paths based on the comprehensive score includes: Select the target transaction path from the candidate transaction paths that has the highest overall score and whose estimated number of tokens received is greater than the user's minimum expected exchange value. When there are multiple transaction paths with the highest overall scores, the transaction path with the fewest hops is determined as the target transaction path based on the path description information corresponding to the candidate transaction paths.

[0011] In one embodiment, after the step of filtering the candidate transaction paths from the candidate transaction paths based on the comprehensive score, the method further includes: For each candidate transaction path, the hash value of the corresponding candidate transaction path is calculated based on the estimated number of tokens to be received, the success rate of path execution, and the comprehensive score. The hash values ​​of each candidate transaction path are used as leaf nodes to construct a Merkle tree. The Merkle tree is uploaded to the distributed file system to generate a corresponding content addressing identifier. This allows the on-chain routing contract to verify that the target transaction path has not been tampered with before executing the target transaction path, based on the Merkle tree corresponding to the content addressing identifier and the Merkle proof.

[0012] In one embodiment, after the step of filtering the candidate transaction paths from the candidate transaction paths based on the comprehensive score, the method further includes: Based on the model evaluation results, transaction preview information is generated for the target transaction path; The transaction preview information, the execution bytecode of the target transaction path, the content addressing identifier, and the Merkel proof corresponding to the target transaction path are returned to the client. When a confirmation transaction message is received from the client regarding the transaction preview information, the target transaction path is encapsulated into an atomic transaction bundle; The transaction bundle is submitted to the Ethereum network through a private channel to ensure that the transaction bundle does not enter the public pool.

[0013] Furthermore, to achieve the above objectives, this application also proposes a path determination device, the path determination device comprising: The determination module is used to respond to a decentralized transaction request and determine multiple candidate transaction paths and the path attributes corresponding to each candidate transaction path based on the transaction parameters in the transaction request. The path evaluation module is used to obtain the real-time transaction environment characteristics on and off the chain for each candidate transaction path. Based on the real-time transaction environment characteristics and the path attributes, the module outputs the model evaluation results through a preset path evaluation model. The model evaluation results include the estimated number of tokens to be received and the path execution success rate. The preset path evaluation model is trained on a preset sparse hybrid expert network based on decentralized transaction samples. The first calculation module is used to calculate the comprehensive score of each candidate transaction path based on the estimated number of tokens to be received and the success rate of path execution. The filtering module is used to filter out the target transaction path from the candidate transaction paths based on the comprehensive score.

[0014] In addition, to achieve the above objectives, this application also proposes a path determination device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the path determination method as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the path determination method described above.

[0016] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the path determination method described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: This application responds to decentralized transaction requests by determining multiple candidate transaction paths and corresponding path attributes for each candidate path based on the transaction parameters in the transaction request. Instead of relying on manual rules to judge the merits of paths, this application acquires real-time on-chain and off-chain transaction environment characteristics for each candidate transaction path. Based on these real-time transaction environment characteristics and the path attributes, a preset path evaluation model outputs a model evaluation result. The model evaluation result includes the estimated number of tokens to be received and the path execution success rate. Based on the estimated number of tokens to be received and the path execution success rate, a comprehensive score is calculated for each candidate transaction path. Based on the comprehensive score, a target transaction path is selected from the candidate transaction paths.

[0018] Since the preset path evaluation model is trained on a preset sparse hybrid expert network based on decentralized transaction samples, the model can learn the complex nonlinear relationship between different transaction environment characteristics and the actual execution results of the path (e.g., the actual amount received, whether it is successful) from the decentralized transaction samples. Furthermore, the sparse hybrid expert network can improve inference efficiency while maintaining high model capacity by dynamically activating expert sub-networks related to the current transaction environment characteristics, thereby more accurately predicting the estimated amount of tokens received and the success rate of path execution for each candidate transaction path.

[0019] Based on the real-time trading environment characteristics and the path attributes, this application outputs model evaluation results, including the estimated number of tokens to be received and the success rate of path execution, through a preset path evaluation model. This model evaluation result is closer to the user's actual goal than a single rule threshold. Based on the estimated number of tokens to be received and the success rate of path execution, a comprehensive score is calculated for each candidate trading path. Based on the comprehensive score, the target trading path selected from the candidate trading paths is more likely to achieve optimal execution at the current moment.

[0020] Therefore, the method described in this application can more accurately evaluate and select target execution paths in complex and rapidly changing decentralized trading environments. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0022] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1This is a flowchart illustrating the path determination method of this application in Embodiment 1. Figure 2 This is a schematic diagram of the module structure of the path determination device according to an embodiment of this application; Figure 3 This is a schematic diagram of the device structure of the hardware operating environment involved in the path determination method in the embodiments of this application.

[0024] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0025] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0026] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0027] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or path determination device capable of performing the above functions. The following description uses a path determination device as an example to illustrate this embodiment and the subsequent embodiments.

[0028] Based on this, embodiments of this application provide a path determination method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the path determination method of this application.

[0029] In this embodiment, the path determination method includes steps S10 to S40: Step S10: In response to the decentralized transaction request, determine multiple candidate transaction paths and the path attributes corresponding to each candidate transaction path based on the transaction parameters in the transaction request; Step S20: For each candidate transaction path, obtain the real-time transaction environment characteristics on-chain and off-chain. Based on the real-time transaction environment characteristics and the path attributes, output the model evaluation result through the preset path evaluation model. The model evaluation result includes the estimated number of tokens to be received and the path execution success rate. The preset path evaluation model is trained on a preset sparse hybrid expert network based on decentralized transaction samples. Step S30: Calculate the comprehensive score for each candidate transaction path based on the estimated number of tokens to be received and the success rate of the path execution; Step S40: Based on the comprehensive score, select the target transaction path from the candidate transaction paths.

[0030] It should be noted that the path determination device can belong to a decentralized exchange. When receiving a decentralized transaction request initiated by a user or front-end application, the path determination device parses the transaction parameters in the decentralized transaction request.

[0031] For example, a user clicks the Swap button on the front-end interface, triggering the swap() function. This function collects the user's input parameters, including but not limited to the trading pair, quantity, and slippage tolerance, and performs preliminary validation to ensure that basic transaction requirements are met. The swap() function sends a request to the backend microservice A of the path determination device through the application programming interface. The request body contains information such as the user's address, trading pair, input quantity, slippage tolerance, and signature. After receiving the request, backend microservice A first verifies the user's address permissions to confirm that the user has sufficient token balance and authorized amount.

[0032] The transaction parameters include at least one of the following: Source Token: The type of token the user wants to sell or exchange; Target Token: The type of token the user wants to obtain; Transaction Quantity: The amount of source tokens the user plans to invest; Acceptable Slippage Range; Maximum Hops Limit: Used to limit the maximum number of liquidity pools allowed to pass through in the path; Supported Protocol Whitelist / Blacklist: For example, only specific DEX protocols such as Uniswap V2 / V3, Balancer, and Curve are considered.

[0033] Furthermore, the path determination device determines multiple candidate transaction paths and the corresponding path attributes of each candidate transaction path based on the transaction parameters in the transaction request; each candidate transaction path consists of an ordered sequence of liquidity pools.

[0034] The path attribute includes at least one of the following: Structural attributes: path hop count, list of protocols involved, whether it includes a stable pool, whether it is cross-chain, etc. Static transaction attributes: transaction fee rate of each pool, minimum transaction limit, etc. Dynamic snapshot attributes: current reserve amount of each pool, price oracle quote (if any), transaction throughput of the most recent block, etc. Security attributes: whether the pool contract has been audited, whether it has been included in the malicious address database, whether the anti-front-running mechanism has been enabled, etc.

[0035] Specifically, the implementation method of determining multiple candidate transaction paths and the path attributes corresponding to each candidate transaction path based on the transaction parameters in the transaction request can also be as follows: a high-frequency exchange pattern can be pre-mined from on-chain historical transaction data to construct a path template library; when a new transaction request is received, the source token and the target token are first matched to see if they exist in the template library. If they do, the corresponding template path is directly instantiated as a candidate path; each instantiated path is accompanied by its corresponding path attributes.

[0036] In one feasible implementation, the step of determining multiple candidate transaction paths based on the transaction parameters in the transaction request may be: The transaction parameters in the transaction request are standardized and encapsulated to obtain the order message; the transaction status data of all transaction pools related to the order message are obtained from the blockchain in real time; a directed weighted graph is constructed based on the transaction status data, wherein the nodes of the directed weighted graph are different tokens, the edges are transaction pools connecting two tokens, and the weight of the edges is determined based on the transaction fee cost and the estimated Gas (transaction fee) consumption; based on the directed weighted graph and preset constraints, multiple candidate transaction paths are searched through a preset shortest path model, wherein the preset constraints include at least a preset maximum number of hops, single pool depth, and cumulative transaction fee.

[0037] The path determination device first parses and standardizes the received decentralized transaction requests, encapsulating the transaction parameters into a structured order message. This order message serves as a unified input interface for subsequent data acquisition and path planning, ensuring consistency in the internal processing of the decentralized exchange. For example, after the aforementioned permission verification is successful, microservice A calls the authentication service and converts the request into a unified order message. Microservice A then passes the encapsulated order message to microservice B of the path determination device. Microservice B receives the order message and obtains the transaction status data of all transaction pools related to the order message from the blockchain in real time.

[0038] Microservice B then uses the source and target tokens in the order message to query in real time all liquidity pools directly or indirectly related to the token pair in the current block through blockchain nodes or decentralized indexing services; thereby obtaining the transaction status data of all transaction pools related to the order message; wherein the obtained transaction status data includes at least: The contract addresses and protocol types of each pool; current reserves; transaction fee rates; whether centralized liquidity is enabled in the pool; and the transaction activity of the most recent block, etc.

[0039] Furthermore, based on the aforementioned transaction state data, microservice B constructs a dynamic directed weighted graph. Nodes represent different tokens, and edges connect transaction pools between two tokens. The weight of each edge is determined by transaction fees and estimated gas consumption. This graph structure is dynamically updated with each new block to ensure it reflects the latest on-chain state.

[0040] Based on the constructed directed weighted graph, the path determination device calls a preset shortest path model to perform path search. The search process must meet the following preset constraints: maximum number of hops limit: for example, limiting the path to a maximum of 3 liquidity pools to avoid overly complex paths; single pool depth constraint: excluding pools with insufficient reserves to support the current transaction (e.g., slippage greater than 5%); cumulative fee cap: filtering paths whose total fees exceed the user's expected fees. Alternatively, the preset constraints may also include a protocol whitelist / blacklist (allowing or prohibiting specific DEX protocols from participating in path construction).

[0041] Through graph search under the above constraints, the system outputs the first few (e.g., the first 200) candidate transaction paths with low costs and that meet the feasibility criteria. Each path consists of a series of ordered liquidity pools and includes its corresponding path attributes, such as hop count, protocol sequence, total weight (i.e., overall cost), reserve ratio of each pool, and estimated number of tokens to be output.

[0042] It is understood that this embodiment transforms the complex multi-pool routing problem into a constrained graph theory optimization problem, utilizes mature graph algorithms to achieve efficient and interpretable path generation, and balances economic costs and network execution costs through dynamic weight design.

[0043] Furthermore, the path determination device performs a refined dynamic evaluation for each candidate transaction path to predict its actual performance under the current market and network conditions. This evaluation no longer relies on static rules, but is achieved through a pre-defined path evaluation model (based on a sparse mixture-of-experts network, Sparse MoE).

[0044] Although the total parameters of a sparse hybrid expert network can reach billions or even tens of billions, only 1-2 expert subnetworks are dynamically activated during each inference (e.g., selecting 2 from 64 experts), while the remaining parameters remain frozen. This mechanism of high capacity plus sparse activation enables the model to capture complex decentralized transaction environment states and achieve sub-millisecond inference in edge servers or cloud functions.

[0045] Based on decentralized transaction samples, the pre-defined path evaluation model trained on a pre-defined sparse hybrid expert network can learn the high-dimensional nonlinear mapping relationship between on-chain environmental characteristics, path structure attributes, and actual execution results from massive historical decentralized transaction samples. For example, under the combination of high MEV (Maximal Extractable Value) activity and low liquidity pools, even if the theoretical slippage is low, the actual transaction may still be significantly degraded due to front-running. Cross-protocol multi-hop paths are more cost-effective than direct-connect pools within a certain Gas price range. Traditional rules or linear models are difficult to capture such interaction effects, while the pre-defined sparse hybrid expert network, with its large-capacity expert sub-network, can automatically identify and model these complex patterns.

[0046] For each candidate path, the path determination device pulls on-chain and off-chain transaction environment features in real time from blockchain nodes or decentralized data indexing services. The on-chain environment features include at least 70 dimensions such as block status, pool status, token liquidity, pool reserves, fee level, and 24-hour trading volume. The off-chain transaction environment features include at least 50 dimensions such as the active count of MEV robots in the mempool, the average MEV return in the past hour, the spread of mainstream CEXs, and social sentiment.

[0047] For each candidate path, the on-chain environment features, off-chain transaction environment features, and path attributes are constructed into a unified multi-dimensional feature vector, which serves as the input to a preset path evaluation model. The preset path evaluation model outputs the model evaluation results, which include the estimated number of tokens to be credited and the path execution success rate. The estimated number of tokens to be credited reflects economic benefits, while the path execution success rate reflects transaction robustness. This ensures that routing decisions no longer solely pursue "maximum output" but also consider realizability, thus better aligning with users' actual interests.

[0048] Through the sparse activation mechanism described above, the model maintains a capacity of tens of billions of parameters while reducing the amount of floating-point operations per inference by more than an order of magnitude. It can achieve an end-to-end evaluation latency of less than 100ms on general cloud servers or edge nodes, enabling the aggregator to quickly return to the optimal path after the user clicks Swap.

[0049] The path determination device calculates a comprehensive score for each candidate transaction path based on the estimated number of tokens to be received and the success rate of path execution from the model output. This comprehensive score is used to uniformly measure the balance between returns and risks.

[0050] Specifically, a weighted utility function can be used to balance the user's dual demands for maximizing benefits and ensuring execution reliability. The weights can be dynamically adjusted based on user profiles or explicit settings. For example, conservative users value success rate more, while aggressive users prioritize maximizing output.

[0051] Alternatively, the implementation method for calculating the comprehensive score of each candidate transaction path based on the estimated number of tokens received and the path execution success rate can also be: Based on the success rate of the path execution, a failure risk weight is determined; based on the failure risk weight and a preset risk penalty coefficient, a risk penalty value is calculated, wherein the preset risk penalty coefficient is used to characterize the equivalent failure cost, and the equivalent failure cost is determined based on the failure cost knowledge learned by the preset reinforcement learning model; based on the estimated number of tokens to be received and the risk penalty value, a comprehensive score for each candidate transaction path is calculated.

[0052] This embodiment employs a risk-adjusted scoring mechanism based on reinforcement learning (RL). By modeling transaction path selection as an expected return maximization problem, failure costs are explicitly introduced to suppress the recommendation of high-risk paths.

[0053] Vectorize and parallelize all paths to improve computational efficiency; calculate the overall score (Score) for each path (Pi). ; in, This indicates the actual number of target tokens the user can receive if the path is successfully executed. λ represents the failure probability of the path, serving as the failure risk weight; λ is a preset risk penalty coefficient, used to characterize the equivalent economic loss caused by a failed transaction.

[0054] Specifically, the equivalent failure cost is determined based on the failure cost knowledge learned by the preset reinforcement learning model; for example, the RL agent tries different paths in a simulated environment, and obtains a positive reward (plus the actual amount received) for successful transactions and imposes a negative reward (minus the implicit failure cost) for failed transactions; after a large amount of training, the reinforcement learning model converges to the equivalent loss caused by each failure on average in the current market environment.

[0055] It can be understood that the failure probability F = 1 - the success rate of path execution, and this failure probability is used as the failure risk weight to quantify the potential failure possibility of the path.

[0056] In this embodiment, λ is defined as 2000 USDC, which means that if a transaction fails, the user loses an average of 2000 USDC (US dollars) in potential value (e.g., due to missing the best execution window, incurring additional gas due to having to re-initiate the transaction, or being exposed to price volatility risk).

[0057] This embodiment transforms the failure cost knowledge learned through reinforcement learning into practical routing scoring rules, effectively avoiding the shortcomings of traditional aggregators that only look at the output, and significantly improving the reliability of transactions and user experience in high-value or high-risk environments.

[0058] Furthermore, after obtaining the comprehensive score of all candidate paths, the final path selection is performed. All candidate paths can be sorted in descending order; the final filtering can be carried out through the following inviolable hard constraints: minimum success probability threshold, maximum gas cost cap, and protocol blacklist, etc.

[0059] Alternatively, the implementation method of selecting the target transaction path from the candidate transaction paths based on the comprehensive score can also be: The target transaction path with the highest overall score and the estimated number of tokens received is greater than the user's expected minimum exchange value is selected from the candidate transaction paths. When there are multiple transaction paths with the highest overall scores, the transaction path with the fewest hops is determined as the target transaction path based on the path description information corresponding to the candidate transaction paths.

[0060] Specifically, multiple candidate transaction paths can be screened in two levels. The first level of screening: satisfying the user's minimum profit constraint, only retaining the set of transaction paths that meet the following condition: the estimated amount of tokens to be credited is greater than the expected minimum exchange value specified by the user in the transaction request (which can be automatically calculated by the front end based on the input amount and maximum slippage). This ensures that the recommended path will not cause the user's actual income to fall below the acceptable threshold due to excessive slippage, avoiding situations where the theoretical score is high but the actual usability is poor.

[0061] Second-level screening: Among the transaction paths that have passed the first-level screening, the one with the highest overall score is selected as the preliminary preferred path.

[0062] The third level of screening: If multiple paths in the initial selection have the same highest overall score (e.g., due to rounding or discretization of model output), then their path hop counts are further compared, and the path with the fewest hops is selected as the final target transaction path. Fewer hops mean shorter transaction call data and lower gas consumption; simultaneously, fewer cross-pool attempts reduce the risk of overall failure due to sudden changes in intermediate pool states. This significantly improves the actual transaction quality and user experience of decentralized transactions.

[0063] It should be noted that once candidate transaction paths are determined, if the path is found to involve cross-chain elements (e.g., bridge contracts or cross-chain messaging), cross-chain risk assessment features can be further introduced on top of the existing real-time transaction environment characteristics and path attributes. These cross-chain risk assessment features include: bridge security score (a dynamic security score generated based on multi-source on-chain data for the cross-chain bridges used in the path), verifiable delayed execution (for cross-chain solutions supporting VDE mechanisms, estimating the additional costs required to ensure the target chain transaction is executed within a specified time window), target chain future state prediction (using the target chain Gas price prediction model and liquidity trend model to predict the Gas cost and pool depth when executing the exchange after a cross-chain delay period (e.g., 5 minutes), and volatility premium (quantifying the price uncertainty risk during cross-chain transmission based on the current and historical volatility of the source and target chain token pairs).

[0064] The aforementioned cross-chain risk assessment features are combined with existing real-time transaction environment features and path attributes, and then fed into a pre-defined sparse hybrid expert network as input. This internalizes cross-chain uncertainty during the assessment phase, avoids overestimating the value of high-risk bridging paths, and significantly improves the reliability of cross-chain transaction recommendations and the security of user funds.

[0065] This embodiment introduces a sparse hybrid expert network into the decentralized exchange's aggregation routing layer, enabling the selection of the optimal transaction path with up to 5 hops within millisecond-level latency. By synchronously acquiring over 100 dimensions of real-time features from both on-chain and off-chain sources every 200ms, the sparse hybrid expert network accurately outputs the estimated number of tokens to be credited and the execution success rate for each path, significantly improving the accuracy of users' exchange expectations and the transaction success rate.

[0066] Based on the first embodiment of this application, in the second embodiment of this application, the same or similar content as the above embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, the specific implementation method of outputting the model evaluation result through a preset path evaluation model according to the real-time transaction environment characteristics and the path attributes can be as follows: Scan the public memory pool and private transaction pool in the blockchain network to identify unprocessed transactions in the public memory pool and private transaction pool whose transaction direction is the same as the transaction request; extract MEV risk characteristics from the unprocessed transactions; and output model evaluation results through a preset path evaluation model based on the MEV risk characteristics, real-time transaction environment characteristics and path attributes.

[0067] It should be noted that although the current DEX ecosystem has introduced private trading pools such as Flashbots to avoid arbitrage by sandwich bots, during peak trading periods, many users still broadcast their trades to the public mempool due to gas competition or client limitations. The public mempool itself lacks MEV awareness and protection mechanisms, making it highly vulnerable to sandwich attacks, resulting in a severe deterioration of the actual transaction price for users.

[0068] The path determination device described in this application monitors and aggregates off-chain transactions (i.e., pending transactions) in real time from public mempools of mainstream chains such as Ethereum and from accessed private transaction pools. For example, it can deploy a lightweight off-chain crawler service to scan in real time at 200ms intervals: the public mempools of blockchain nodes and the public submission streams of mainstream private transaction pools such as Flashbots.

[0069] For each pending transaction, its input / output tokens, transaction direction, amount, and target contract are analyzed. From this, a set of pending transactions with the same transaction direction as the current transaction request (e.g., both from USDC to WETH (Wrapped Ether)) are selected as potential sources of competition or pincer attacks.

[0070] The MEV risk characteristics extracted from the above pending transactions include at least one of the following: Number of currently active clamping bot addresses; average clamping bot earnings (USDC equivalent) in the past hour; density of large orders in the same direction (frequency of transactions in the same direction greater than 10k USD); percentage of sandwich structured transactions; ratio of private pool submission rate to public pool exposure rate; bot address clustering popularity; proportion of high gas preemption transactions; historical clamping success rate; MEV searcher activity index; number of transactions in the same direction; frequency of large preemption transactions, etc.

[0071] The MEV risk characteristics are fused with real-time trading environment characteristics and path attributes to form an enhanced input feature vector, which is then input into a preset path evaluation model. Based on this enhanced input, the model outputs a more accurate model evaluation result.

[0072] It is understandable that if the model detects a significant increase in MEV risk during the evaluation process (e.g., a sudden increase in robot activity), it will automatically lower the success rate of that path. By lowering the success rate of that path, it can avoid recommending high-risk paths to users.

[0073] In this embodiment, by introducing real-time MEV signals at the memory pool level, the aggregator is equipped with proactive MEV resistance capabilities: it not only senses risks but also suppresses the selection of high-risk paths through model-endogenous feedback. This embodiment significantly improves the robustness and foresight of path evaluation in high-adversarial environments, enabling the aggregator to proactively avoid high-risk paths, thereby further improving the actual transaction quality and fund security for users.

[0074] Based on the first and second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, after the step of selecting the target transaction path from the candidate transaction paths according to the comprehensive score, the following can also be added: After completing on-chain execution, the actual execution result of the target transaction path is obtained, wherein the actual execution result includes the actual number of tokens received, the actual gas consumption cost, and the maximum extractable value (MEV) loss; the reward value is calculated based on the actual execution result and the estimated number of tokens received. Using the real-time transaction environment features as state features and the target transaction path as an action, a decentralized transaction sample is constructed based on the state features, actions, and reward value, and written into a message queue. Multiple historical transaction samples are continuously retrieved from the message queue in real time to form a training batch. The state features in the training batch are input into the preset path evaluation model to obtain a strategy output and a value output. The strategy output is the probability distribution of the selection of each candidate transaction path, and the value output is an estimate of the expected cumulative return for the selected action. A deep Q-network loss is calculated based on the reward value and the value output, and a strategy gradient loss is calculated based on the reward value and the value output. The gradient is calculated through backpropagation based on the deep Q-network loss, the strategy gradient loss, and preset loss weights. Only the low-rank adaptation matrix embedded in the preset path evaluation model is updated to update the path evaluation model.

[0075] It is understood that this embodiment introduces a closed-loop reinforcement learning feedback mechanism to achieve continuous online evolution of the path evaluation model.

[0076] Specifically, the selected target transaction path is executed through a general routing contract (such as a smart contract that supports multi-hop and cross-protocol calls) deployed on the chain. After the on-chain execution is completed, the actual execution result of the target transaction path is obtained. The actual execution result can be extracted from the transaction receipt and on-chain logs after the transaction is confirmed on the chain.

[0077] The actual execution results include the actual number of tokens received, the actual gas consumption cost, and the loss of the maximum extractable value (MEV).

[0078] Furthermore, a reinforcement learning reward signal is constructed. Specifically, the reward value for this interaction can be calculated based on the actual execution result and the estimated number of tokens received. This reward truly reflects the user's net economic gain in this transaction and serves as a supervisory signal for reinforcement learning. The real-time transaction environment characteristics are used as state characteristics, and the target transaction path is used as an action. Based on the state characteristics, actions, and reward value, a decentralized transaction sample is constructed. That is, the DEX routing problem is formally modeled as a Markov Decision Process (MDP).

[0079] Regardless of whether a transaction succeeds or fails, the triple (state, action, reward) is immediately serialized and written to a high-throughput distributed message queue upon confirmation, forming a continuously growing experience replay buffer. Specifically, the sample can be asynchronously written to a high-throughput message queue (such as Kafka or Pulsar) for subsequent model training, decoupling the routing service from model training and ensuring low latency on the core path.

[0080] The training service module pulls multiple historical transaction samples (e.g., thousands accumulated within the last 10 minutes) from the message queue in real time to form a training batch. The state features of the training batch are input into the preset path evaluation model to obtain a policy output and a value output. The policy output is the probability distribution of selecting each candidate transaction path, and the value output is an estimate of the expected cumulative reward for the selected action. Based on the reward value and the value output, two types of losses are calculated using either the standard Actor-Critic framework or a combination of both, and Deep Q-Network (DQN): Deep Q-Network loss (to measure the value output relative to the target reward) and policy gradient loss (to optimize the policy output based on the advantage function to increase the probability of high-reward actions).

[0081] The above losses are weighted and summed according to preset weights to obtain the total loss function. Subsequently, backpropagation and gradient updates are performed only on the low-rank adaptation matrix embedded in the model evaluated along the preset path, and the backbone MoE parameters are frozen. This method significantly reduces training computational overhead and memory usage, supports hot model updates every 10 minutes, and eliminates the need for full retraining.

[0082] It should be noted that, in constructing decentralized transaction samples, this embodiment can enhance the labeling granularity and training weights for cross-chain transaction scenarios. Specifically, based on the original actual execution results, key fields are added: cross-chain latency (the time from locking on the source chain to receiving funds on the target chain), whether bridging failure occurred (such as bridge contract rollback or verification timeout), and the deviation between the actual slippage and the estimated slippage on the target chain, in order to accurately characterize the uncertainty of cross-chain execution.

[0083] When calculating the reinforcement learning reward value, a cross-chain specific reward function is introduced: if the asset is completely lost due to a bridge security vulnerability, a severe penalty is imposed; if the final value received is lower than expected due to delay or market fluctuations, a dynamic penalty is imposed based on the deviation magnitude and delay duration; conversely, if the system achieves better-than-expected returns through oracle-driven path re-optimization, a portion of the excess returns is converted into positive rewards to incentivize the model to explore cross-chain strategies that combine robustness and profitability.

[0084] Furthermore, during the training phase, higher sampling weights are assigned to cross-chain samples. Even if these samples occur at a low frequency, this can accelerate the learning and generalization capabilities of the preset path evaluation model for high-risk, high-impact cross-chain scenarios, thereby continuously improving the reliability of cross-chain transactions and the level of user fund protection.

[0085] In this embodiment, an end-to-end online reinforcement learning closed loop is constructed to realize the real-time self-evolution capability of the preset path evaluation model.

[0086] Based on the first, second, and third embodiments of this application, in the fourth embodiment of this application, the content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter. In addition, after the step of selecting the target transaction path from the candidate transaction paths based on the comprehensive score, the method further includes: For each candidate transaction path, the hash value of the corresponding candidate transaction path is calculated based on the estimated number of tokens to be received, the success rate of path execution, and the comprehensive score. The hash values ​​of each candidate transaction path are used as leaf nodes to construct a Merkle tree. The Merkle tree is uploaded to the distributed file system to generate a corresponding content addressing identifier. This identifier is used by the on-chain routing contract to verify that the target transaction path has not been tampered with before executing the target transaction path, based on the Merkle tree corresponding to the content addressing identifier and the Merkle proof.

[0087] This embodiment primarily addresses the rule black-box problem prevalent in current DEX aggregators: due to the closed-source nature of routing strategies, the community cannot verify whether they truly select the optimal path, often leading to trust disputes such as prioritizing traffic to partner liquidity pools. To enhance the integrity, verifiability, and tamper resistance of transaction paths, this embodiment further introduces Merkle trees.

[0088] Specifically, in this embodiment, for each candidate transaction path, the corresponding key evaluation results—estimated number of tokens to be received, path execution success rate, and comprehensive score—are structured and processed, and a cryptographic hash function is used to calculate its path hash value.

[0089] A binary Merkle tree is constructed from the bottom up, using the hash values ​​of all candidate paths as leaf nodes. The root node is the Merkle root. The entire Merkle tree is then serialized and uploaded to a decentralized distributed file system, which returns a Content Identifier (CID).

[0090] Before the target transaction path is actually executed through the on-chain routing contract, the front-end or relay service provides the user device or trusted validator with: the model evaluation result corresponding to the target transaction path, the corresponding Merkle proof (i.e., the sibling hash path from the hash value corresponding to the target transaction path to the Merkle root), and the content addressing identifier.

[0091] Users or off-chain validators can complete tamper-proof verification through the following steps: recalculate the hash value of the target transaction path; reconstruct the Merkle root using the Merkle proof and the recalculated hash value; obtain the original root node from the distributed file system via CID; if the reconstructed Merkle root is the same as the original root node, it proves that the evaluation result of the path has not been tampered with by a man-in-the-middle and can be executed securely.

[0092] Optionally, on-chain routing contracts can also integrate lightweight verification logic (such as injecting CID and proof via an oracle) to achieve on-chain auditability.

[0093] Specifically, after the step of selecting the target transaction path from the candidate transaction paths based on the comprehensive score, the method further includes: Based on the model evaluation results, transaction preview information is generated for the target transaction path; the transaction preview information, the execution bytecode of the target transaction path, the content addressing identifier, and the Merkle proof corresponding to the target transaction path are returned to the client; when a confirmation transaction message is received from the client regarding the transaction preview information, the target transaction path is encapsulated into an atomic transaction bundle; the transaction bundle is submitted to the Ethereum network through a private channel to ensure that the transaction bundle does not enter the public pool.

[0094] To further enhance transaction security, transparency, and MEV resilience, this embodiment generates structured transaction preview information for each candidate transaction path based on its corresponding key evaluation results. This preview information clearly displays to the user: expected exchange result, success rate estimate, risk warnings, and path details.

[0095] The transaction preview information, the execution bytecode of the target transaction path (i.e., calldata, used to call the on-chain routing contract), the content addressing identifier (pointing to the Merkle tree stored on IPFS), and the Merkle proof corresponding to the target transaction path (used to verify that the path is indeed the path with the highest public score).

[0096] Users can independently verify whether the recommended path truly originates from an authentic, unaltered set of candidates using lightweight verification tools (such as browser plugins or wallet built-in modules), thereby eliminating concerns about black-box traffic redirection.

[0097] This addresses the community's core concern regarding whether aggregators secretly replace paths to redirect traffic to the collaboration pool. Once verified, it can be confirmed that the executed path meets the constraints set by the user at that time (such as minimum output, maximum slippage, and deadline), and is the optimal choice under the model's evaluation at that moment.

[0098] Once the client receives the user's confirmation message regarding the transaction preview information, the decentralized exchange encapsulates the target transaction path into an atomic transaction bundle, ensuring that multi-hop exchanges are completed within a single transaction and avoiding exposure of intermediate states. This bundle is not broadcast to the public mempool but is submitted directly to the Ethereum consensus layer through a private transaction channel. This mechanism effectively prevents transactions from being monitored, copied, or subjected to sandwich attacks by bots in the public pool, significantly reducing the risk of MEV loss.

[0099] For example, after the client confirms that everything is correct, it clicks the confirmation button and authorizes the transaction intent with a secondary signature through its wallet. After the front-end sends the confirmation request, off-chain simulation is performed to verify feasibility. Microservice A calls the built-in AI simulation execution engine to perform atomic simulation of the complete transaction process in an isolated offline client environment through the transaction simulation interface. This verifies whether the target token has actually arrived, whether the actual gas consumption is reasonable, and whether there are any risks of drawdown (such as insufficient balance, pool exhaustion, missing authorization, etc.). Only when the simulation execution is completely successful and the results meet expectations can the process proceed to the next step.

[0100] After the simulation succeeds, microservice A packages the entire transaction process into an atomic transaction bundle: if any sub-operation fails, the entire transaction will be rolled back, and the state will be completely reversed. This bundle is then submitted to the Ethereum network via private transaction channels such as Flashbots Protect, bypassing the public mempool and avoiding monitoring or attacks by MEV bots. Finally, the bundle is included in an Ethereum block. The bridge contract successfully locks 9.98 ETH and issues a Locked event; upon hearing this event, the bridge validator triggers the corresponding operation on the Solana network, for example, performing a Swap in the Orca USDC / SOL (USD / Solana) pool, ultimately depositing 223.4 SOL into the client's wallet.

[0101] This embodiment introduces Merkle trees and distributed storage into the DEX aggregation routing process for the first time, achieving cryptographic-level integrity protection for candidate path evaluation results. Even if the aggregator backend is compromised or subjected to a man-in-the-middle attack, users can still independently verify that the executed path matches its original score, effectively preventing malicious behaviors such as recommending high-scoring paths and executing low-quality paths. This mechanism significantly improves the system's transparency, auditability, and user trust.

[0102] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the path determination method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0103] This application also provides a path determination device, please refer to... Figure 2 The path determination device includes: The determination module 10 is used to respond to a decentralized transaction request and determine multiple candidate transaction paths and the path attributes corresponding to each candidate transaction path based on the transaction parameters in the transaction request. The path evaluation module 20 is used to obtain the real-time transaction environment characteristics on and off the chain for each candidate transaction path, and output the model evaluation results through the preset path evaluation model based on the real-time transaction environment characteristics and the path attributes. The model evaluation results include the estimated number of tokens to be received and the path execution success rate. The preset path evaluation model is trained on a preset sparse hybrid expert network based on decentralized transaction samples. The first calculation module 30 is used to calculate the comprehensive score of each candidate transaction path based on the estimated number of tokens to be received and the success rate of path execution. The filtering module 40 is used to filter the target transaction path from the candidate transaction paths based on the comprehensive score.

[0104] In one embodiment, the path evaluation module 20 includes: The identification submodule is used to scan the public memory pool and private transaction pool in the blockchain network, and identify unprocessed transactions in the public memory pool and private transaction pool whose transaction direction is the same as the transaction request. An extraction submodule is used to extract MEV risk characteristics from the transactions to be processed. The model evaluation submodule is used to output model evaluation results based on the MEV risk characteristics, real-time trading environment characteristics, and path attributes through a preset path evaluation model.

[0105] In one embodiment, the first computing module 30 includes: The first determining submodule is used to determine the failure risk weight based on the success rate of the path execution; The first calculation submodule is used to calculate the risk penalty value based on the failure risk weight and the preset risk penalty coefficient, wherein the preset risk penalty coefficient is used to characterize the equivalent failure cost, and the equivalent failure cost is determined based on the failure cost knowledge learned by the preset reinforcement learning model. The second calculation submodule is used to calculate the comprehensive score of each candidate transaction path based on the estimated number of tokens to be received and the risk penalty value.

[0106] In one embodiment, after the step of filtering the candidate transaction paths from the candidate transaction paths based on the comprehensive score, the apparatus further includes: The acquisition module is used to acquire the actual execution result of the target transaction path after the on-chain execution is completed. The actual execution result includes the actual number of tokens received, the actual gas consumption cost, and the maximum extractable value (MEV) loss. The second calculation module is used to calculate the reward value based on the actual execution result and the estimated number of tokens received; The construction module is used to take the real-time transaction environment characteristics as state characteristics, the target transaction path as actions, construct decentralized transaction samples based on the state characteristics, actions and reward values, and write the decentralized transaction samples into a message queue. The pull module is used to continuously pull multiple historical transaction samples from the message queue in real time to form a training batch; The path evaluation module is used to input the state features in the training batch into the preset path evaluation model to obtain strategy output and value output, wherein the strategy output is the selection probability distribution of each candidate transaction path, and the value output is the expected cumulative return estimate for the selected action. The third calculation module is used to calculate the deep Q-network loss based on the reward value and the value output, and to calculate the policy gradient loss based on the reward value and the value output. The update module is used to calculate the gradient through backpropagation based on the deep Q-network loss, the policy gradient loss, and the preset loss weights, and update the parameters only for the low-rank adaptation matrix embedded in the preset path evaluation model, so as to update the path evaluation model.

[0107] In one embodiment, the determining module 10 includes: The encapsulation submodule is used to standardize and encapsulate the transaction parameters in the transaction request to obtain the order message; The acquisition submodule is used to obtain the transaction status data of all transaction pools related to the order message from the chain in real time; A construction submodule is used to construct a directed weighted graph based on the transaction status data. The nodes of the directed weighted graph are different tokens, and the edges are transaction pools connecting two tokens. The weight of the edges is determined based on the transaction fee cost and the estimated gas consumption. The search submodule is used to search for multiple candidate transaction paths based on the directed weighted graph and preset constraints using a preset shortest path model. The preset constraints include at least a preset maximum number of hops, single pool depth, and cumulative transaction fees.

[0108] In one embodiment, the filtering module 40 includes: The filtering submodule is used to filter the target transaction path with the highest comprehensive score from the candidate transaction paths, and whose estimated number of tokens to be received is greater than the user's expected minimum exchange value; The second determination submodule is used to determine the transaction path with the fewest hops as the target transaction path when there are multiple transaction paths with the highest comprehensive scores, based on the path description information corresponding to the candidate transaction paths.

[0109] In one embodiment, after the step of filtering the candidate transaction paths from the candidate transaction paths based on the comprehensive score, the apparatus further includes: The third calculation module is used to calculate the hash value of each candidate transaction path based on the estimated number of tokens to be received, the success rate of path execution, and the comprehensive score. The hash value of each candidate transaction path is used as a leaf node to construct a Merkle tree. The first generation module is used to upload the Merkle tree to the distributed file system and generate a corresponding content addressing identifier, so that the on-chain routing contract can verify that the target transaction path has not been tampered with before executing the target transaction path, based on the Merkle tree corresponding to the content addressing identifier and the Merkle proof.

[0110] In one embodiment, after the step of filtering the candidate transaction paths from the candidate transaction paths based on the comprehensive score, the apparatus further includes: The second generation module is used to generate transaction preview information for the target transaction path based on the model evaluation results; The return module is used to return the transaction preview information, the execution bytecode of the target transaction path, the content addressing identifier, and the Merkel proof corresponding to the target transaction path to the client. An encapsulation module is used to encapsulate the target transaction path into an atomic transaction bundle when it receives a confirmation transaction message from the client regarding the transaction preview information. The submission module is used to submit the transaction bundle to the Ethereum network through a private channel to ensure that the transaction bundle does not enter the public pool.

[0111] The path determination apparatus provided in this application, employing the path determination method in the above embodiments, can solve the technical problem that routing logic driven by fixed rules cannot accurately select the execution path in complex or rapidly changing execution environments. Compared with the prior art, the beneficial effects of the path determination apparatus provided in this application are the same as those of the path determination method provided in the above embodiments, and other technical features in the path determination apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0112] This application provides a path determination device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the path determination method in Embodiment 1 above.

[0113] The following is for reference. Figure 3 The diagram illustrates a structural schematic suitable for implementing the path determination device in the embodiments of this application. The path determination device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, tablets, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital televisions and desktop computers. Figure 3 The path determination device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0114] like Figure 3As shown, the path determination device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the path determination device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the path determination device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows path determination devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0115] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0116] The path determination device provided in this application, employing the path determination method in the above embodiments, can solve the technical problem that routing logic driven by fixed rules cannot accurately select the execution path in complex or rapidly changing execution environments. Compared with the prior art, the beneficial effects of the path determination device provided in this application are the same as those of the path determination method provided in the above embodiments, and other technical features of this path determination device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0117] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0118] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations 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. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0119] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the path determination method in the above embodiments.

[0120] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0121] The aforementioned computer-readable storage medium may be included in the path-determining device; or it may exist independently and not assembled into the path-determining device.

[0122] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the path-determining device, cause the path-determining device to perform the aforementioned path-determining method.

[0123] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0124] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0125] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0126] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described path determination method. This solves the technical problem that routing logic driven by fixed rules cannot accurately select execution paths in complex or rapidly changing execution environments. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the path determination method provided in the above embodiments, and will not be repeated here.

[0127] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the path determination method described above.

[0128] The computer program product provided in this application can solve the technical problem that routing logic driven by fixed rules cannot accurately select the execution path in complex or rapidly changing execution environments. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the path determination method provided in the above embodiments, and will not be repeated here.

[0129] The above descriptions are merely some embodiments of this application and do not limit the scope of protection of this application. Any equivalent structural transformations made based on the technical concept of this application and the content of this specification and drawings, or direct / indirect applications in other related technical fields, are included within the scope of protection of this application. All actions involving the acquisition of signals, information, or data in this application are performed in accordance with the relevant data protection laws and policies of the country where the application is located and with authorization from the owner of the corresponding device.

Claims

1. A path determination method, characterized in that, The path determination method includes: In response to a decentralized transaction request, multiple candidate transaction paths and path attributes corresponding to each candidate transaction path are determined based on the transaction parameters in the transaction request. For each candidate transaction path, real-time transaction environment characteristics on-chain and off-chain are obtained. Based on the real-time transaction environment characteristics and the path attributes, the model evaluation results are output through a preset path evaluation model. The model evaluation results include the estimated number of tokens to be received and the path execution success rate. The preset path evaluation model is trained on a preset sparse hybrid expert network based on decentralized transaction samples. Based on the estimated number of tokens to be credited and the success rate of the path execution, calculate the comprehensive score for each candidate transaction path; Based on the comprehensive score, the target transaction path is selected from the candidate transaction paths.

2. The path determination method as described in claim 1, characterized in that, The step of outputting model evaluation results based on the real-time trading environment characteristics and the path attributes using a preset path evaluation model includes: Scan the public memory pool and private transaction pool in the blockchain network to identify unprocessed transactions in the public memory pool and private transaction pool whose transaction direction is the same as the transaction request; Extract MEV risk characteristics from the pending transactions; Based on the MEV risk characteristics, real-time trading environment characteristics, and path attributes, the model evaluation results are output through a preset path evaluation model.

3. The path determination method as described in claim 1, characterized in that, The step of calculating the comprehensive score for each candidate transaction path based on the estimated number of tokens received and the path execution success rate includes: Determine the failure risk weight based on the success rate of the path execution; The risk penalty value is calculated based on the failure risk weight and the preset risk penalty coefficient, wherein the preset risk penalty coefficient is used to characterize the equivalent failure cost, and the equivalent failure cost is determined based on the failure cost knowledge learned by the preset reinforcement learning model. The overall score for each candidate transaction path is calculated based on the estimated number of tokens to be credited and the risk penalty value.

4. The path determination method as described in claim 1, characterized in that, After the step of selecting the target transaction path from the candidate transaction paths based on the comprehensive score, the method further includes: After completing the on-chain execution, the actual execution result of the target transaction path is obtained, wherein the actual execution result includes the actual number of tokens received, the actual gas consumption cost, and the maximum extractable value (MEV) loss. The reward value is calculated based on the actual execution results and the estimated number of tokens received. The real-time transaction environment features are used as state features, the target transaction path is used as an action, and a decentralized transaction sample is constructed based on the state features, actions, and reward value. The decentralized transaction sample is then written into a message queue. Multiple historical transaction samples are continuously pulled from the message queue in real time to form a training batch; The state features in the training batch are input into the preset path evaluation model to obtain strategy output and value output, wherein the strategy output is the selection probability distribution of each candidate transaction path, and the value output is the expected cumulative return estimate for the selected action. Calculate the deep Q-network loss based on the reward value and the value output, and calculate the policy gradient loss based on the reward value and the value output. Based on the deep Q-network loss, the policy gradient loss, and the preset loss weights, the gradient is calculated through backpropagation, and the parameters are updated only on the low-rank adaptation matrix embedded in the preset path evaluation model to update the path evaluation model.

5. The path determination method as described in claim 1, characterized in that, The step of determining multiple candidate transaction paths based on the transaction parameters in the transaction request includes: The transaction parameters in the transaction request are standardized and encapsulated to obtain the order message; Obtain real-time transaction status data of all transaction pools related to the order message from the blockchain; A directed weighted graph is constructed based on the transaction status data, wherein the nodes of the directed weighted graph are different tokens, the edges are transaction pools connecting two tokens, and the weight of the edges is determined based on the transaction fee cost and the estimated gas consumption. Based on the directed weighted graph and preset constraints, multiple candidate transaction paths are obtained by searching through a preset shortest path model. The preset constraints include at least a preset maximum number of hops, single pool depth, and cumulative transaction fees.

6. The path determination method as described in claim 1, characterized in that, The step of selecting the target transaction path from the candidate transaction paths based on the comprehensive score includes: Select the target transaction path from the candidate transaction paths that has the highest overall score and whose estimated number of tokens received is greater than the user's minimum expected exchange value. When there are multiple transaction paths with the highest overall scores, the transaction path with the fewest hops is determined as the target transaction path based on the path description information corresponding to the candidate transaction paths.

7. The path determination method as described in claim 1, characterized in that, After the step of selecting the target transaction path from the candidate transaction paths based on the comprehensive score, the method further includes: For each candidate transaction path, the hash value of the corresponding candidate transaction path is calculated based on the estimated number of tokens to be received, the success rate of path execution, and the comprehensive score. The hash values ​​of each candidate transaction path are used as leaf nodes to construct a Merkle tree. The Merkle tree is uploaded to the distributed file system to generate a corresponding content addressing identifier. This allows the on-chain routing contract to verify that the target transaction path has not been tampered with before executing the target transaction path, based on the Merkle tree corresponding to the content addressing identifier and the Merkle proof.

8. The path determination method as described in claim 7, characterized in that, After the step of selecting the target transaction path from the candidate transaction paths based on the comprehensive score, the method further includes: Based on the model evaluation results, transaction preview information is generated for the target transaction path; The transaction preview information, the execution bytecode of the target transaction path, the content addressing identifier, and the Merkel proof corresponding to the target transaction path are returned to the client. When a confirmation transaction message is received from the client regarding the transaction preview information, the target transaction path is encapsulated into an atomic transaction bundle; The transaction bundle is submitted to the Ethereum network through a private channel to ensure that the transaction bundle does not enter the public pool.

9. A path determination device, characterized in that, The path determination device includes: The determination module is used to respond to a decentralized transaction request and determine multiple candidate transaction paths and the path attributes corresponding to each candidate transaction path based on the transaction parameters in the transaction request. The path evaluation module is used to obtain the real-time transaction environment characteristics on and off the chain for each candidate transaction path. Based on the real-time transaction environment characteristics and the path attributes, the module outputs the model evaluation results through a preset path evaluation model. The model evaluation results include the estimated number of tokens to be received and the path execution success rate. The preset path evaluation model is trained on a preset sparse hybrid expert network based on decentralized transaction samples. The first calculation module is used to calculate the comprehensive score of each candidate transaction path based on the estimated number of tokens to be received and the success rate of path execution. The filtering module is used to filter out the target transaction path from the candidate transaction paths based on the comprehensive score.

10. A path determination device, characterized in that, The path determination device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the path determination method as described in any one of claims 1 to 8.

Images