Test method, device and equipment for Solana chain node

Abstract

The invention relates to a Solana chain node-oriented test method, device and equipment. The Solana chain node-oriented test method provided by the invention comprises the following steps: dividing a plurality of transactions in a target test item into a plurality of transaction clusters, and selecting a plurality of alternative transaction clusters from the plurality of transaction clusters; submitting the plurality of transaction clusters to the tested node by taking the cluster as a unit so as to indicate the tested node to execute the transaction according to a cluster-level parallel processing mechanism, and returning a first execution result; submitting the plurality of alternative transaction clusters to the isolation equipment by taking the cluster as a unit, so as to indicate the isolation equipment to play back the plurality of alternative transaction clusters, and returning a second execution result; receiving the first execution result and the second execution result, and comparing the consistency of the first execution result and the second execution result to obtain a comparison result; identifying the attack event according to the first execution result to obtain an identification result; and storing the first execution result, the second execution result, the comparison result and the identification result so as to carry out comprehensive and systematic test and analysis on the Solana chain node.

Description

Technical Field

[0001] This application relates to the field of testing technology, and in particular to a testing method, apparatus and device for Solana chain nodes. Background Technology

[0002] Solana Chain, with its high throughput and parallel transaction execution mechanism, has been widely adopted in the blockchain ecosystem. As the ecosystem has developed, various third-party services have emerged, relying on Solana Chain's parallel execution and efficient consensus mechanism to support and optimize on-chain transactions. However, high-concurrency transactions and complex transaction patterns simultaneously present potential performance bottlenecks and security risks. Therefore, systematic testing and monitoring of Solana Chain nodes are crucial for ensuring network security, optimizing node performance, and improving the overall stability of the ecosystem.

[0003] Because the Solana chain employs a parallel transaction execution mechanism and a high-throughput design, traditional testing methods cannot be applied to the Solana chain. Summary of the Invention

[0004] This embodiment provides a testing method, apparatus, and device for Solana chain nodes, enabling comprehensive and systematic testing and analysis of Solana chain nodes.

[0005] The first aspect of this application provides a testing method for Solana chain nodes, the method comprising:

[0006] The multiple transactions in the target test project are divided into multiple transaction clusters, and multiple candidate transaction clusters for replay are selected from the multiple transaction clusters.

[0007] The multiple transaction clusters are submitted to the node under test in units of clusters to instruct the node under test to execute the transactions according to the cluster-level parallel processing mechanism and return the first execution result corresponding to the multiple transaction clusters;

[0008] The multiple candidate transaction clusters are submitted to the isolation device in cluster form, so that the isolation device can replay the multiple candidate transaction clusters and return the second execution result corresponding to the multiple candidate transaction clusters;

[0009] Receive the first execution result and the second execution result, and compare the consistency between the first execution result and the second execution result to obtain a comparison result;

[0010] Based on the first execution result, the attack event is identified, and the identification result is obtained;

[0011] The first execution result, the second execution result, the comparison result, and the identification result are stored.

[0012] A second aspect of this application provides a testing device for Solana chain nodes, the testing device including a partitioning module, an execution module, a processing module, and an auditing module;

[0013] The segmentation module is used to divide multiple transactions in the target test project into multiple transaction clusters, and select multiple candidate transaction clusters for replay from the multiple transaction clusters;

[0014] The execution module is used to submit the multiple transaction clusters to the node under test in units of clusters, so as to instruct the node under test to execute the transactions according to the cluster-level parallel processing mechanism and return the first execution result corresponding to the multiple transaction clusters;

[0015] The execution module is further configured to submit the plurality of candidate transaction clusters to the isolation device in units of clusters, so as to instruct the isolation device to replay the plurality of candidate transaction clusters and return the second execution result corresponding to the plurality of candidate transaction clusters;

[0016] The processing module is configured to receive the first execution result and the second execution result, and compare the consistency between the first execution result and the second execution result to obtain a comparison result;

[0017] The processing module is further configured to identify attack events based on the first execution result and obtain an identification result;

[0018] The audit module is used to store the first execution result, the second execution result, the comparison result, and the identification result.

[0019] A third aspect of this application provides a test device for Solana chain nodes, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described in any of the first aspects of this application.

[0020] A fourth aspect of this application provides a computer program product including a computer program / instructions that, when executed by a processor, implement the method described in any of the first aspects of this application.

[0021] The testing method, apparatus, and equipment for Solana chain nodes provided in this application divide multiple transactions in a target test project into multiple transaction clusters, select multiple candidate transaction clusters for replay from these clusters, and then submit the multiple transaction clusters to the node under test for execution as a cluster. The multiple candidate transaction clusters are also submitted to an isolation device for execution as a cluster. The system receives the first execution result from the node under test and the second execution result from the isolation device. Furthermore, based on this, the consistency between the first and second execution results can be compared to obtain a comparison result. Attack events can be identified based on the first execution result to obtain an identification result. Finally, the first execution result, the second execution result, the comparison result, and the identification result are stored uniformly. This enables comprehensive and systematic observation of the execution behavior of Solana chain nodes, providing reliable data support for subsequent auditing, performance optimization, and security protection, and achieving systematization, refinement, and traceability of node testing. Furthermore, by dividing transactions into clusters and submitting them in cluster units, node behavior can be effectively verified in high-throughput environments, accurately capturing node behaviors such as transaction reordering and transaction loss. Moreover, by cross-validating through dual paths of the tested node and the isolation device, the consistency of node execution behavior can be determined, and potential anomalies can be identified in a timely manner.

[0022] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

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

[0024] Figure 1 A flowchart of an embodiment of the testing method for Solana chain nodes provided in this application;

[0025] Figure 2 This diagram illustrates an application scenario of a testing method for Solana chain nodes, as shown in an exemplary embodiment of this application.

[0026] Figure 3 A flowchart of Embodiment 2 of the testing method for Solana chain nodes provided in this application;

[0027] Figure 4 A flowchart of Embodiment 3 of the testing method for Solana chain nodes provided in this application;

[0028] Figure 5 A flowchart of Embodiment 4 of the testing method for Solana chain nodes provided in this application;

[0029] Figure 6 This is a hardware structure diagram of a test device for Solana chain nodes, illustrating an exemplary embodiment of this application.

[0030] Figure 7 This is a schematic diagram of the first embodiment of the test device for Solana chain nodes provided in this application. Detailed Implementation

[0031] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0032] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0033] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0034] The following specific embodiments are given to illustrate the technical solution of this application in detail.

[0035] Figure 1 This is a flowchart of an embodiment of the testing method for Solana chain nodes provided in this application. Please refer to... Figure 1 The method provided in this embodiment may include:

[0036] S101. Divide multiple transactions in the target test project into multiple transaction clusters, and select multiple candidate transaction clusters for replay from the multiple transaction clusters.

[0037] Specifically, Figure 2 This diagram illustrates an application scenario of a testing method for Solana chain nodes, as shown in an exemplary embodiment of this application. Please refer to... Figure 2The method provided in this embodiment is applied to a testing system, which includes a testing device for Solana chain nodes, a node under test, and an isolation device. Specifically, the method provided in this embodiment is applied to a testing device for Solana chain nodes, which can be a computer.

[0038] It should be noted that the node under test can be any node on the Solana chain. The isolation device, on the other hand, is an independent local blockchain simulation device that is completely isolated from the node under test and is unaffected by network latency, node stress, or external attacks. It is used to generate reference execution results.

[0039] The following is combined Figure 1 and Figure 2 The method provided in this embodiment will be described in detail.

[0040] Specifically, the target test item is a set of transactions used to evaluate the performance, security, and parallel processing capabilities of Solana chain nodes, which contains multiple transactions.

[0041] The target test project includes multiple transactions of various types, covering different scenarios. For example, it may include ordinary transfer transactions, DEXswap transactions (target transactions), attack transactions (pre-attack, post-attack, sandwich attack), and random interference transactions.

[0042] The specific content of each type of transaction is pre-set by the testers according to actual needs; in this embodiment, it is not limited. For example, by injecting features into transactions, attack transactions can be constructed to facilitate the identification of attack transactions from ordinary transactions.

[0043] It should be noted that the features injected into a transaction are set according to actual needs, and this embodiment does not limit them. In specific implementation, the following features can be injected into a transaction:

[0044] (1) Basic characteristics of transaction level (required): target contract, client submission time, which node to which the submission is made, transaction fees, etc.;

[0045] (2) Account / dependency related characteristics (used to identify conflicts): clearly list the read and write accounts for each transaction, the number of transactions that conflict with this transaction, whether it contains high-frequency access accounts, etc.

[0046] (3) Time / sorting features.

[0047] For example, in one possible implementation, if a transaction belongs to the same liquidity pool as the target transaction, then an injection feature is used to characterize the transaction, and the computational unit (CU) is set higher than that of ordinary transactions to simulate potential queue-jumping or front-running behavior.

[0048] In specific implementation, this step, based on the Solana chain account model (transactions within the same account must be serial, while transactions between different accounts can be parallel), divides multiple transactions in the target test project into multiple transaction clusters according to the account isolation principle (i.e., intra-cluster transactions involve different accounts, intra-cluster transactions can be executed in parallel as much as possible, and inter-cluster transactions are allowed to overlap accounts to simulate real on-chain conflict scenarios).

[0049] It should be noted that transactions within the same transaction cluster do not have write-write or read-write conflicts in terms of account access. Transactions within each transaction cluster can be submitted in parallel as much as possible. However, when there are dependencies within a transaction cluster, they must be executed serially or in topological order. Conflicts may exist between different transaction clusters. The submission order and PoH time window are recorded.

[0050] Optionally, in one possible implementation, multiple transactions in the target test project can be divided into multiple transaction clusters as follows:

[0051] (1) Based on the account access relationship of the transactions and the dependency order between the transactions, the multiple transactions are conflict identified to obtain the conflict identification result.

[0052] Specifically, conflict identification includes two aspects. First, it determines whether two transactions have account conflicts, that is, whether the two transactions have a dependency relationship when accessing the same account, affecting whether they can be executed in parallel. Second, even if two transactions do not have account conflicts, but have logical dependencies (e.g., T2 must use the execution result of T1, then T2 and T1 have a logical dependency), then these two transactions still need to be executed serially.

[0053] Regarding the first aspect, in specific implementation, conflicts can be identified as follows: For each transaction T, the set of accounts read is denoted as RT, the set of accounts written is denoted as WT, and the set of all accounts involved in transaction T is denoted as AT, where AT = RT ∪ WT. For any two transactions T1 and T2, if the following conditions are met: ,and If T1 and T2 do not have account conflicts, they can be executed in parallel; otherwise, T1 and T2 have account conflicts and need to be executed sequentially.

[0054] Regarding the second aspect, a topology check can be performed directly based on the transaction logic dependencies. If there is a dependency order, it is considered to be in conflict and needs to be executed serially; otherwise, it is considered not to be in conflict and can be executed in parallel.

[0055] (2) Based on the conflict identification results and the pre-set cluster division rules, the multiple transactions are divided into multiple transaction clusters; wherein, the pre-set cluster division rules are used to constrain the size of each transaction cluster, the proportion of different types of transactions in each transaction cluster, and the ratio of serial transactions to parallel transactions within the cluster.

[0056] It should be noted that the pre-defined cluster partitioning rules are set according to actual needs, and are not limited in this embodiment. For example, in one possible implementation, the pre-defined cluster partitioning rules can be: the size of each transaction cluster is: each transaction cluster contains 10 to 500 transactions, and the proportions of ordinary transfer transactions, DEXswap transactions (target transactions), attack transactions (pre-attack, post-attack, sandwich attack), and random interference transactions are set to A, B, C, D, and E, respectively, and the ratio of parallel transactions and serial transactions within the cluster is F. Here, A, B, C, D, E, and F are parameters that can be adjusted according to actual needs, and their specific values ​​are not limited in this embodiment.

[0057] Furthermore, after dividing the transaction clusters, a unique identifier is assigned to each cluster and associated with a PoH timestamp to track the cluster's status in real time, enabling full lifecycle management of the transaction clusters. The status of a transaction cluster includes: pending submission, processing, and verification completed.

[0058] Referring to the preceding description, after dividing the multiple transactions in the target test project into multiple transaction clusters, the next step is to select multiple candidate transaction clusters for replay from these clusters. Specifically, in one possible implementation, a predetermined sampling ratio of transaction clusters can be randomly selected from the multiple clusters, and these selected clusters can be used as candidate transaction clusters.

[0059] It should be noted that the preset extraction ratio is set according to actual needs, and is not limited in this embodiment. For example, in one possible implementation, the preset extraction ratio can be 10% to 100%.

[0060] S102. Submit the multiple transaction clusters to the node under test in cluster units to instruct the node under test to execute transactions according to the cluster-level parallel processing mechanism and return the first execution result corresponding to the multiple transaction clusters.

[0061] As mentioned earlier, the node under test is the node on the Solana chain that needs to be tested. In this step, multiple transaction clusters will be submitted to the node under test.

[0062] In practice, multiple transaction clusters can be submitted to the node under test in parallel to ensure that the test results reflect the behavior of the node under test under real network conditions.

[0063] Specifically, the test device for Solana chain nodes (hereinafter referred to as the test device) adopts a multi-threaded structure, with each thread bound to an independent network connection, supporting a parallel submission rate of 100 to 1000 clusters per second. In addition, the submission strictly follows the PoH timing logic, generating a simulated logical timestamp for each transaction to ensure that the relative order of transactions within a cluster conforms to the Solana chain's parallel processing rules.

[0064] Understandably, after receiving a transaction cluster, the tested node can execute conflict-free transactions in parallel within the cluster, provided there are no account conflicts, and execute conflicting transactions sequentially according to their dependency order. Finally, it returns the first execution result corresponding to multiple transaction clusters.

[0065] It should be noted that the first execution result includes information such as the execution status, execution time, execution duration, and execution impact of each transaction in multiple transaction clusters.

[0066] S103. Submit the multiple candidate transaction clusters to the isolation device in cluster units, so as to instruct the isolation device to replay the multiple candidate transaction clusters and return the second execution result corresponding to the multiple candidate transaction clusters.

[0067] Specifically, the test device submits multiple candidate transaction clusters to the isolation device in cluster units. Furthermore, after receiving the candidate transaction clusters, the isolation device executes the transaction clusters in a controlled environment, strictly following the dependency order of transactions within the cluster and account isolation rules, and returns the second execution results corresponding to the multiple candidate transaction clusters.

[0068] It should be noted that the second execution result includes information such as the execution status, execution time, execution duration, and execution impact of each transaction in the multiple candidate transaction clusters.

[0069] Referring to the preceding description, the method provided in this embodiment, by dividing transaction clusters and submitting them in cluster units, can verify node behavior in high-throughput environments and accurately capture node behaviors such as transaction reordering and deadlock.

[0070] S104. Receive the first execution result and the second execution result, and compare the consistency between the first execution result and the second execution result to obtain a comparison result.

[0071] Referring to step S103, after the tested node completes multiple transaction clusters, it returns a first execution result to the test device. Similarly, after the isolation device completes multiple alternative transaction clusters, it returns a second execution result to the test device. In this step, the test device receives the first and second execution results and compares their consistency to obtain a comparison result.

[0072] It is understandable that the first execution result is the result of the tested node executing multiple transaction clusters in a real network environment, while the second execution result is the result of the isolation device replaying multiple candidate transaction clusters in an ideal environment. In this step, the comparison result can be obtained by comparing the first execution result of the tested node with the second execution result of the isolation device in multiple dimensions. For example, in one embodiment, the actual impact of the transaction on the blockchain state, such as changes in account balance and liquidity pool price, can be compared to determine whether the execution results are consistent, so as to accurately detect abnormal behavior of the tested node in transaction processing.

[0073] S105. Identify the attack event based on the first execution result and obtain the identification result.

[0074] In practice, the time series, account relationships, and economic characteristics of transactions can be analyzed to identify transaction combinations that match the attack characteristics, thus obtaining the identification results. For example, in one possible implementation, if a "pre-target-post" time relationship is detected within the same pool based on the first execution result, and the preceding and following transactions cause opposite changes in the pool price, and the preceding and following transactions are executed by the same control account, then a sandwich attack is confirmed to exist; if only a "pre-target" or "target-post" time relationship is detected and the transaction price of the target transaction deteriorates significantly compared to the benchmark, then a pre-attack or post-attack is confirmed to exist.

[0075] Optionally, in one possible implementation, the method further includes: generating a test report corresponding to the attack event when an attack event is detected; wherein the test report includes multiple fields for characterizing attack features and node response behavior, the multiple fields including at least: attack type, hash identifier of related transaction, PoH timestamp, target transaction loss amount, processing time, and processing behavior information of the tested node.

[0076] It should be noted that by performing baseline replay of the same transaction on the isolated device, a baseline execution result is obtained. Then, by comparing the baseline execution result with the actual execution result of the tested node, the target transaction loss amount can be calculated.

[0077] Processing time is represented by the difference between the node's receiving time and the transaction confirmation time. The processing behavior of the node under test can be recorded in the node log, which records the node's rejection of certain transactions, etc.

[0078] The method provided in this embodiment generates a test report corresponding to the detected attack event, enabling the tracing and auditing of the attack event. Simultaneously, the test report reflects the relationship between attack characteristics and node response capabilities, providing data support for security analysis, performance evaluation, and node optimization.

[0079] S106. Store the first execution result, the second execution result, the comparison result, and the identification result.

[0080] In practice, for example, the first execution result, the second execution result, the comparison file, and the recognition result can be stored simultaneously locally and / or in the cloud.

[0081] Optionally, in one possible implementation, the process of storing the first execution result, the second execution result, the comparison result, and the identification result may include:

[0082] Store the first execution result, the second execution result, the comparison result, and the identification result locally; calculate the hash values ​​of the first execution result, the second execution result, the comparison result, and the identification result respectively; determine the root hash of all hash values, and write the root hash into the Solana chain.

[0083] Specifically, a specified hash algorithm can be used to calculate the hash value of each type of data. The specific type of the specified hash algorithm is set according to actual needs, and is not limited in this embodiment. For example, in one possible implementation, the specified hash algorithm can be SHA-256, SHA-384, SHA-512, etc.

[0084] Furthermore, following the Merkle tree rules, these hash values ​​can be combined in pairs and hashed again, recursively upwards until a unique root hash is generated. Finally, the root hash can be written to the Solana chain via on-chain transactions or by calling a smart contract. Solana's Proof-of-Hero (PoH) mechanism records the submission time, binding the root hash to a precise timestamp to achieve an immutable proof of time.

[0085] It should be noted that by generating a root hash from the hash values ​​of the execution results, comparison results, and identification results and writing it into the Solana chain, on the one hand, the root hash, which is anchored on the chain and is tamper-proof, can prevent test data from being tampered with and improve the credibility of the test data; on the other hand, combined with the PoH timestamp, it is possible to accurately trace back the time of the event, which is convenient for post-event auditing and tracing, while reducing the dependence on local storage security and enhancing data sharing and verification capabilities.

[0086] The method provided in this embodiment divides multiple transactions in the target test project into multiple transaction clusters, selects multiple candidate transaction clusters for replay from these clusters, and then submits the multiple transaction clusters to the node under test for execution, and submits the multiple candidate transaction clusters to the isolation device for execution, receiving the first execution result from the node under test and the second execution result from the isolation node. Furthermore, based on this, the consistency of the first and second execution results can be compared to obtain a comparison result, and attack events can be identified based on the first execution result to obtain an identification result. Finally, the first execution result, the second execution result, the comparison result, and the identification result are uniformly stored. This enables comprehensive and systematic observation of the execution behavior of Solana chain nodes, providing reliable data support for subsequent auditing, performance optimization, and security protection, achieving systematic, refined, and traceable node testing. In addition, by dividing transaction clusters and submitting them in cluster units, node behavior can be effectively verified in high-throughput environments, accurately capturing node behaviors such as transaction reordering and transaction loss. Furthermore, cross-validation through dual paths between the node under test and the isolation device can determine the consistency of node execution behavior and promptly identify potential anomalies.

[0087] Figure 3 This is a flowchart of Embodiment 2 of the testing method for Solana chain nodes provided in this application. Please refer to... Figure 3 The method provided in this embodiment may include:

[0088] S301. Based on the first execution result, construct a relational graph to depict the interaction between transactions, accounts, and liquidity pools.

[0089] In practice, we can first traverse the transaction data and create transaction nodes; traverse all accounts and create account nodes; traverse all involved pools and create pool nodes. Further, we can traverse the transaction data to create edges between the transaction initiator and the transaction; create edges between the transaction and the pool; and create edges between the account and the pool, thus obtaining a relationship graph.

[0090] For example, in one embodiment, assume that three transactions are in the same transaction cluster, with a time sequence of T1 → T2 → T3, and that: T1: Attacker (AccA) buys PoolX in advance; T2: Victim (AccB) trades in PoolX (is sandwiched); T3: Attacker (AccA) sells PoolX in the latter.

[0091] At this point, the constructed relationship graph can be represented as:

[0092]

[0093] This relationship diagram illustrates the following: AccA initiated transaction T1, which was executed on PoolX, causing a change in the pool price. Subsequently (approximately 5ms later), the victim AccB initiated transaction T2, also executed on PoolX, and thus traded at the price affected by the preceding transaction. Then (approximately 3ms later), AccA initiated transaction T3, performing a reverse operation (e.g., selling) on ​​PoolX, thus profiting from the arbitrage.

[0094] S302. Search the association graph for candidate ternary paths that meet the preset filtering conditions.

[0095] In practice, pattern matching is performed on the association graph to search for ternary paths containing "pre-transaction - target transaction - subsequent transaction". The preset filtering conditions include: the three transactions constituting the ternary path are executed sequentially within a preset time window, and the three transactions operate on the same liquidity pool or the same trading pair.

[0096] It should be noted that the preset time window is set according to actual needs, and its specific value is not limited in this embodiment. For example, in one possible implementation, the specific value of the preset time window can be 10 seconds.

[0097] In addition, the three transactions need to be arranged in chronological order, i.e., timestamp (previous transaction) < timestamp (target transaction) < timestamp (follower transaction).

[0098] In a specific implementation, for example, in one possible implementation, the transaction sequence of the same liquidity pool can be monitored, the price slippage before and after the target transaction can be calculated, and if the price slippage increases abnormally (e.g., more than 5%), the target transaction is marked as suspicious, and then the existence of preceding and following transactions is searched before and after the target transaction to find candidate ternary paths.

[0099] S303. For each candidate ternary path, obtain the economic characteristics of each transaction in that candidate ternary path.

[0100] In practical implementation, for each candidate ternary path, the impact of the preceding transaction on the pool's marginal price or median price, Δprice_pr, can be calculated and used as the economic characteristic of the preceding transaction. Further, the deviation of the target transaction's execution price from the reference price before the event, slippage_target, is calculated and used as the economic characteristic of the target transaction. It should be noted that this value reflects the amplification of actual slippage relative to theoretical slippage. Finally, the net profit after the attacker closes their position, profit_attacker, is calculated and used as the economic characteristic of the subsequent transaction.

[0101] S304. Match the economic characteristics of each transaction with the economic characteristics corresponding to each attack type to obtain the matching results.

[0102] It should be noted that each attack type has specific economic characteristics. For example, pre-attacks exhibit directional price-driving characteristics and profit-taking signs. That is, firstly, after the pre-attack occurs, the pool price moves in the direction the attacker desires (e.g., by buying to drive up the price), which can be quantified using Δprice_pre. Secondly, if there is only a pre-attack, it is necessary to observe whether there are subsequent target trades; the evidence for a single pre-attack is weak and is often marked as "suspicious."

[0103] For example, sandwich attacks have the following economic characteristics:

[0104] (1) Front-end transactions cause significant price deviations;

[0105] Δprice_pre is in the expected direction and exceeds the threshold (threshold ≥ 0.5% or higher).

[0106] (2) The target slippage is magnified (actual slippage > theoretical slippage); for example, slippage_target > 5%;

[0107] (3) Post-implementation arbitrage, i.e., profit_attacker > threshold.

[0108] Based on the above description, it can be understood that a sandwich attack has the following economic characteristics: when the attacker sees that someone else is about to execute a transaction, they preemptively send their own transaction (pre-trade) to drive up the price; they wait for the victim's transaction to be executed (target trade); then they send a reverse trade (post-trade) to profit from the price fluctuations caused.

[0109] In this step, the economic characteristics of each transaction in the candidate ternary path are matched with the economic characteristics corresponding to each attack type to obtain the matching result. This result is used to characterize whether the candidate ternary path belongs to an attack event. When the candidate ternary path belongs to an attack event, the specific attack type is given. The attack type specifically includes pre-attack, post-attack and sandwich attack.

[0110] S305. When the matching result indicates that the candidate ternary path conforms to the economic characteristics of a sandwich attack, determine the account correlation between the preceding and following transactions in the candidate ternary path to obtain the correlation result.

[0111] In practice, one approach is to check if the signer of the pre-transaction and the post-transaction are the same. If the signer is the same, the two transactions are considered related; otherwise, they are considered unrelated. Alternatively, one approach is to check if the pre-transaction and the post-transaction share the same control entity. If they do (e.g., sharing an IP address), the two transactions are considered related; otherwise, they are considered unrelated.

[0112] S306. When the correlation result is a correlation, determine that the candidate ternary path constitutes a sandwich attack; otherwise, determine that the candidate ternary path does not constitute a sandwich attack.

[0113] In this embodiment, when the pre-transaction and post-transaction share the same signer or IP address, they are marked as associated. This allows for precise control of the transaction order, verification of the impact of attacks, and generation of auditable evidence, which helps improve the reliability and traceability of the testing method.

[0114] The method provided in this embodiment firstly, by simultaneously verifying time sequence constraints, same pool / same trading pair constraints, and economic feature matching, can comprehensively judge the characteristics of trading behavior from multiple dimensions, thereby significantly improving the recognition rate of real attack events and effectively reducing the false alarm rate; secondly, for sandwich attack scenarios, account correlation analysis is further introduced on the basis of economic feature matching, which can comprehensively judge the fund or control relationship between the preceding and subsequent transactions, thereby further improving the accuracy and reliability of attack detection.

[0115] Figure 4 This is a flowchart of Embodiment 3 of the testing method for Solana chain nodes provided in this application. Please refer to... Figure 4 Based on the above embodiments, the method provided in this embodiment includes both the first execution result and the second execution result, which include the execution time, execution status, execution time, and execution impact of the transaction. The step of comparing the consistency between the first execution result and the second execution result to obtain a comparison result may include:

[0116] S401. Determine the first transaction execution sequence based on the execution time of each transaction in the first execution result, and determine the second transaction execution sequence based on the execution time of each transaction in the second execution result.

[0117] In practice, the execution time of each transaction can be extracted from the first execution result; then, the transactions are sorted in ascending order of timestamps to form the first transaction execution sequence.

[0118] Similarly, the execution time of each transaction is extracted from the second execution result; then, the transactions are sorted in ascending order of timestamps to form the second transaction execution sequence.

[0119] S402. Based on the first transaction execution sequence and the second transaction execution sequence, determine a first result for characterizing sequential consistency.

[0120] Referring to the preceding description, the first execution result includes the execution results corresponding to multiple transaction clusters, while the second execution result includes the execution results corresponding to multiple candidate transaction clusters, where the multiple candidate transaction clusters are a subset of the multiple transaction clusters. In this step, the partial transaction execution sequences corresponding to the multiple candidate transaction clusters are first found from the first transaction execution sequence, and then these partial transaction execution sequences are compared with the second transaction execution sequence.

[0121] In practice, the order deviation index between the two sequences can be calculated. This order deviation index can be the proportion of the longest common subsequence length or the relative order misalignment rate, etc.

[0122] Furthermore, if the order deviation index of the two sequences exceeds a preset threshold (such as 10%), they are marked as having inconsistent order.

[0123] It should be noted that by quantifying the consistency of transaction execution order, deviations in execution order caused by node clock drift, transaction scheduling differences, or network latency can be effectively detected. For example, it can effectively identify whether the node under test is interfering with malicious transactions.

[0124] S403. Based on the execution status of the same transaction in the first execution result and the second execution result, determine a second result to characterize the consistency of the status.

[0125] In practical implementation, firstly, the same transaction with the same transaction hash is found from the first and second execution results. Then, the two execution status fields corresponding to this same transaction are found from the two execution results. Further, these two execution status fields are compared. If the execution statuses match, the transaction status is considered to be matched; if they do not match, the reason for the inconsistency is recorded. For example, in one possible implementation, the same transaction is rejected on the tested node but successfully executed on the isolated node. In this case, the transaction statuses do not match, and the reason for rejection by the tested node is further recorded.

[0126] Furthermore, the state matching rate (which equals the number of transactions with matching states divided by the total number of transactions) can be used as a state consistency indicator.

[0127] S404. Based on the execution time of the same transaction in the first and second execution results, determine a third result to characterize the delay difference.

[0128] In practice, the execution time of the same transaction on the two nodes can be calculated separately, and then the difference Δdelay can be obtained.

[0129] Furthermore, the average or variance of Δdelay for all transactions can be calculated to obtain the overall delay deviation index.

[0130] S405. Based on the execution impact of the same transaction in the first execution result and the second execution result, determine a fourth result to characterize the consistency of the results.

[0131] In practice, execution impact information can be extracted from the transaction logs of the two nodes (this execution impact information may include changes in account balance, contract status modifications, event trigger logs, etc.). Then, an execution impact hash is constructed based on the execution impact data. The two execution impact hashes of the same transaction are then compared. If they match, it means that the execution results are exactly the same. If they do not match, further analysis is performed on the difference fields (such as changes in balance and contract variable values).

[0132] The method provided in this embodiment firstly determines the sequential consistency result by comparing transaction execution sequences, which can effectively identify transaction out-of-order problems caused by network congestion, transaction scheduling differences, or clock skew between nodes, thereby improving the accuracy of timing detection. Secondly, by comparing the execution status and execution time of the same transaction, anomalies in the execution logic or performance of nodes can be accurately located, providing a basis for node performance bottleneck analysis and fault tolerance strategy optimization. Finally, by comparing the impact of transaction execution, the consistency of ledger conversion of each node can be directly verified. By introducing multi-dimensional indicators such as execution time, execution status, execution time, and execution impact in the comparison process, the above method can not only discover hidden differences that are difficult to identify, but also quantify the dynamic consistency degree of the node execution process, enabling comprehensive consistency detection of the execution behavior of Solana chain nodes.

[0133] Figure 5 For the flowchart of Embodiment 4 of the testing method for Solana chain nodes provided in this application, please refer to... Figure 5 Based on the above embodiments, the method further includes:

[0134] S501. Obtain the pressure index of the tested node; the pressure index is used to characterize the processing pressure of the tested node under the current load.

[0135] It should be noted that the stress index of the tested node is used to quantify the node's load level in real time, comprehensively reflecting its CPU utilization, memory usage, transaction queue length, etc. For example, in one possible implementation, CPU utilization can be directly used as the stress index of the tested node.

[0136] For example, in one possible implementation, metrics such as CPU utilization, memory usage, and transaction queue length can be normalized to obtain normalized values ​​for each metric. These normalized values ​​can then be weighted, and the weighted result can be used as a stress index. Understandably, this weighted result is between 0 and 1.

[0137] S502. Dynamically adjust the size and submission interval of the transaction clusters subsequently submitted to the tested node according to the pressure index, and dynamically adjust the proportion of the candidate transaction clusters subsequently submitted to the isolation device according to the pressure index.

[0138] In practice, a maximum pressure threshold can be set. For example, in one possible implementation, the maximum pressure threshold is set to 0.7.

[0139] In this step, when the current pressure index exceeds the maximum pressure threshold, the size of the transaction cluster is reduced, the submission interval is extended, and the proportion of candidate transaction clusters is reduced. For example, in one embodiment, when the current pressure index exceeds the maximum pressure threshold, the size of the transaction cluster is reduced from 500 to 200, the submission interval is increased from 10ms to 30ms, and the proportion of candidate transaction clusters is reduced from 70% to 30%.

[0140] The method provided in this embodiment calculates the pressure index in real time and dynamically adjusts the size of the transaction cluster, the submission interval, and the replay ratio. This forms a closed-loop load adaptive testing system, which can prevent node overload while ensuring testing intensity and avoid evaluation distortion caused by overload, thereby achieving a stable, continuous, and controllable high-concurrency on-chain testing process.

[0141] A more specific embodiment is given below to illustrate the technical solution of this application in detail.

[0142] Specifically, in this embodiment, the test objective is to verify whether a user exchange transaction on a tested node within a high-concurrency cluster will be reordered or trigger a sandwich attack.

[0143] Time precision: Based on the slot and PoH timestamps, the difference is compared at the millisecond / slot level.

[0144] (1) Configure the test transaction cluster and test strategy:

[0145] Test cluster: 3 transactions are submitted simultaneously (T1, T2, T3), T2 is the "target transaction" being observed, and T1 / T3 are possible pre-transaction / post-transaction transactions (simulating normal or attack behavior).

[0146] Submitting Node: Submit the same sequence to both the tested node and the isolated node.

[0147] Specific testing strategies:

[0148] luster_size = number of transactions per cluster, DPR = proportion of alternative transaction clusters, attack_profile = type of injected attack.

[0149] (1) Baseline functional testing

[0150] Objective: To verify basic functions, cluster partitioning, and the smooth operation of primary and backup path links (the primary path refers to the path corresponding to the node under test, and the backup path refers to the path corresponding to the isolated node).

[0151] Key configurations: cluster_size=50~200, DPR=0.1~0.2, attack_profile=none.

[0152] Key execution points: run multiple rounds of short-duration operation and record consistency between primary and backup receipts.

[0153] Test points: transaction success rate, primary / backup difference rate, and cluster partitioning correctness.

[0154] 2. Throughput / Pressure Testing

[0155] Objective: To measure the maximum throughput, latency curve, and extreme behavior of the node.

[0156] Key configurations: cluster_size=500~1000, DPR=0.05~0.15, sustain=10~60min.

[0157] Key points for execution: Gradually increase the pressure, record the peak value, and then roll back to observe the recovery.

[0158] Detection points: TPS, confirmation delay (p95 / p99), and points where the error rate spikes.

[0159] 3. Long-term stability (Soak / Stability)

[0160] Objective: To address resource leaks and performance degradation during long-term operation.

[0161] Key configurations: cluster_size=100~300, DPR=0.1, duration=24~168h.

[0162] Key points for implementation: maintain low to medium concurrency and regularly sample diagnostic data.

[0163] Detection points: memory / FD growth, slowdown trend, queue backlog.

[0164] 4. Sandwich Attack Detection

[0165] Objective: To validate the sandwich, pre- / post-processor recognition capabilities and loss estimation. Key configurations: cluster_size=50~200, DPR=0.3~0.8, attack_profile=basic_sandwich / batch_nested.

[0166] Key execution points: Inject known attack templates into several clusters and replay them with high coverage.

[0167] Detection points: pre / mid / post transaction sequence, price slippage, primary / backup difference, confidence score.

[0168] (2) Test

[0169] In the specific test, T1 / T2 / T3 are grouped into cluster C-1001 and submitted in parallel to the tested node and the isolated node within a short time window, and the execution results of the tested node and the isolated node are collected.

[0170] (3) Consistency comparison

[0171] The corresponding transactions are matched by signature, comparing the Sig signature, Slot block number, Status, and Timestamp.

[0172] If Status is Fail in either path, mark it as failed (retry required or classify as "lost / rejected").

[0173] If the slot or order is inconsistent between the two paths, it is marked as "reordering / insertion / missing".

[0174] If the time difference of the same transaction exceeds a threshold (e.g., > 20ms), it is marked as "delay anomaly".

[0175] For example, in one embodiment, if T2 is 10ms later than the isolated node in the TS of the measured result, exceeding the threshold, then T2 is marked as "delay abnormal".

[0176] (5) Identify attack events

[0177] Based on transaction history, detect whether a typical sandwich pattern of pre-order, target, and post-order exists. For example, in one embodiment, T1 is a buy order that is quickly placed by the same entity or a suspicious account before the target is submitted, and the price retraces after the target is executed, and T3 is a sell order that is associated with the pre-order account. In this case, it is marked as a sandwich attack.

[0178] The method provided in this embodiment enables comprehensive and systematic observation of the execution behavior of Solana chain nodes, providing reliable data support for subsequent auditing, performance optimization, and security protection, and realizing the systematization, refinement, and traceability of node testing.

[0179] Corresponding to the aforementioned embodiment of a testing method for Solana chain nodes, this application also provides an embodiment of a testing apparatus for Solana chain nodes.

[0180] An embodiment of a testing device for Solana chain nodes disclosed in this application can be applied to testing equipment for Solana chain nodes. The device embodiment can be implemented through software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the processor of the testing equipment for Solana chain nodes loading the corresponding computer program instructions from non-volatile memory into memory for execution. From a hardware perspective, such as... Figure 6 As shown, Figure 6 This is a hardware structure diagram of a test device for Solana chain nodes, shown as an exemplary embodiment of this application, except... Figure 6 In addition to the processor, memory, network interface, and non-volatile memory shown, the test equipment for Solana chain nodes may also include other hardware depending on the actual function of the test device for Solana chain nodes, which will not be described in detail here.

[0181] Figure 7 This is a schematic diagram of the structure of an embodiment of the test device for Solana chain nodes provided in this application. Please refer to... Figure 7 The apparatus provided in this embodiment includes a partitioning module 710, an execution module 720, a processing module 730, and an auditing module 740.

[0182] The segmentation module 710 is used to divide multiple transactions in the target test project into multiple transaction clusters, and select multiple candidate transaction clusters for replay from the multiple transaction clusters.

[0183] The execution module 720 is used to submit the multiple transaction clusters to the node under test in units of clusters, so as to instruct the node under test to execute the transactions according to the cluster-level parallel processing mechanism and return the first execution result corresponding to the multiple transaction clusters;

[0184] The execution module 720 is further configured to submit the plurality of candidate transaction clusters to the isolation device in units of clusters, so as to instruct the isolation device to replay the plurality of candidate transaction clusters and return the second execution result corresponding to the plurality of candidate transaction clusters;

[0185] The processing module 730 is configured to receive the first execution result and the second execution result, and compare the consistency between the first execution result and the second execution result to obtain a comparison result;

[0186] The processing module 730 is further configured to identify attack events based on the first execution result and obtain an identification result;

[0187] The audit module 740 is used to store the first execution result, the second execution result, the comparison result, and the identification result.

[0188] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0189] Optionally, in one possible implementation, the processing module 730 is specifically used for:

[0190] Based on the first execution result, construct a relational graph to depict the interaction between transactions, accounts, and liquidity pools;

[0191] Search the correlation graph for candidate ternary paths that meet preset screening criteria; the preset screening criteria include: the three transactions constituting the ternary path are executed sequentially within a preset time window, and the three transactions act on the same liquidity pool or the same trading pair.

[0192] For each candidate ternary path, obtain the economic characteristics of each transaction in that candidate ternary path;

[0193] The economic characteristics of each transaction are matched with the economic characteristics corresponding to each attack type to obtain the matching results;

[0194] When the matching result indicates that the candidate ternary path conforms to the economic characteristics of a sandwich attack, the account correlation between the preceding and following transactions in the candidate ternary path is determined to obtain the correlation result.

[0195] If the correlation result is a correlation, the candidate ternary path is determined to constitute a sandwich attack; otherwise, the candidate ternary path is determined not to constitute a sandwich attack.

[0196] Optionally, in one possible implementation, both the first execution result and the second execution result include the execution time, execution status, execution time, and execution impact of the transaction; the processing module 730 is specifically used for:

[0197] The first transaction execution sequence is determined based on the execution time of each transaction in the first execution result, and the second transaction execution sequence is determined based on the execution time of each transaction in the second execution result;

[0198] Based on the first transaction execution sequence and the second transaction execution sequence, a first result is determined to characterize sequential consistency;

[0199] Based on the execution status of the same transaction in the first execution result and the second execution result, a second result is determined to characterize the consistency of the status;

[0200] Based on the execution time of the same transaction in the first and second execution results, a third result is determined to characterize the latency difference;

[0201] A fourth result is determined to characterize the consistency of the results based on the execution impact of the same transaction in the first and second execution results.

[0202] Optionally, in one possible implementation, the multiple transactions in the target test project include various types; the segmentation module 710 is specifically used for:

[0203] Based on the account access relationship and the dependency order between transactions, conflict identification is performed on the multiple transactions to obtain conflict identification results;

[0204] Based on the conflict identification results and the pre-defined clustering rules, the multiple transactions are divided into multiple transaction clusters; wherein, the pre-defined clustering rules are used to constrain the size of each transaction cluster, the proportion of different types of transactions in each transaction cluster, and the ratio of serial transactions to parallel transactions within the cluster.

[0205] Optionally, in one possible implementation, the processing module 730 is further specifically used for:

[0206] Obtain the pressure index of the tested node; the pressure index is used to characterize the processing pressure of the tested node under the current load;

[0207] The size of the transaction clusters and the submission interval of the transaction clusters subsequently submitted to the tested node are dynamically adjusted based on the pressure index.

[0208] The proportion of candidate transaction clusters subsequently submitted to the isolation device is dynamically adjusted based on the pressure index.

[0209] Optionally, in one possible implementation, the processing module 730 is further configured to generate a test report corresponding to the attack event when an attack event is detected; wherein the test report includes multiple fields for characterizing attack features and node response behavior, the multiple fields including at least: attack type, hash identifier of related transaction, PoH timestamp, target transaction loss amount, processing time, and processing behavior information of the tested node.

[0210] Optionally, in one possible implementation, the audit module 740 is specifically used for:

[0211] The first execution result, the second execution result, the comparison result, and the identification result are stored locally.

[0212] Calculate the hash values ​​of the first execution result, the second execution result, the comparison result, and the identification result, respectively;

[0213] Determine the root hash of all hash values ​​and write the root hash into the Solana chain.

[0214] Please continue to refer to Figure 6 This application also provides a test device for Solana chain nodes, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described in any of the first aspects of this application.

[0215] This application also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the method described in any of the first aspects of this application.

[0216] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0217] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A testing method for Solana chain nodes, characterized in that, The method includes: The multiple transactions in the target test project are divided into multiple transaction clusters, and multiple candidate transaction clusters for replay are selected from the multiple transaction clusters. The multiple transaction clusters are submitted to the node under test in units of clusters to instruct the node under test to execute the transactions according to the cluster-level parallel processing mechanism and return the first execution result corresponding to the multiple transaction clusters; The multiple candidate transaction clusters are submitted to the isolation device in cluster form, so that the isolation device can replay the multiple candidate transaction clusters and return the second execution result corresponding to the multiple candidate transaction clusters; Receive the first execution result and the second execution result, and compare the consistency between the first execution result and the second execution result to obtain a comparison result; Based on the first execution result, the attack event is identified, and the identification result is obtained; The first execution result, the second execution result, the comparison result, and the identification result are stored.

2. The method according to claim 1, characterized in that, The step of identifying attack events based on the first execution result and obtaining the identification result includes: Based on the first execution result, a relational graph is constructed to depict the interaction between transactions, accounts, and liquidity pools; Search the correlation graph for candidate ternary paths that meet preset screening criteria; the preset screening criteria include: the three transactions constituting the ternary path are executed sequentially within a preset time window, and the three transactions act on the same liquidity pool or the same trading pair. For each candidate ternary path, obtain the economic characteristics of each transaction in that candidate ternary path; The economic characteristics of each transaction are matched with the economic characteristics corresponding to each attack type to obtain the matching results; When the matching result indicates that the candidate ternary path conforms to the economic characteristics of a sandwich attack, the account correlation between the preceding and following transactions in the candidate ternary path is determined to obtain the correlation result. If the correlation result is positive, the candidate ternary path is determined to constitute a sandwich attack; otherwise, the candidate ternary path is determined not to constitute a sandwich attack.

3. The method according to claim 1, characterized in that, Both the first execution result and the second execution result include the execution time, execution status, execution time, and execution impact of the transaction; the comparison of the consistency between the first execution result and the second execution result to obtain the comparison result includes: The first transaction execution sequence is determined based on the execution time of each transaction in the first execution result, and the second transaction execution sequence is determined based on the execution time of each transaction in the second execution result; Based on the first transaction execution sequence and the second transaction execution sequence, a first result is determined to characterize sequential consistency; Based on the execution status of the same transaction in the first execution result and the second execution result, a second result is determined to characterize the consistency of the status; Based on the execution time of the same transaction in the first and second execution results, a third result is determined to characterize the latency difference; A fourth result is determined to characterize the consistency of the results based on the execution impact of the same transaction in the first and second execution results.

4. The method according to claim 1, characterized in that, The multiple transactions in the target test project include various types; the process of dividing the multiple transactions in the target test project into multiple transaction clusters includes: Based on the account access relationship and the dependency order between transactions, conflict identification is performed on the multiple transactions to obtain conflict identification results; Based on the conflict identification results and the pre-defined clustering rules, the multiple transactions are divided into multiple transaction clusters; wherein, the pre-defined clustering rules are used to constrain the size of each transaction cluster, the proportion of different types of transactions in each transaction cluster, and the ratio of serial transactions to parallel transactions within the cluster.

5. The method according to claim 1, characterized in that, The method further includes: Obtain the pressure index of the tested node; the pressure index is used to characterize the processing pressure of the tested node under the current load; The size of the transaction clusters and the submission interval of the transaction clusters subsequently submitted to the tested node are dynamically adjusted based on the pressure index. The proportion of candidate transaction clusters subsequently submitted to the isolation device is dynamically adjusted based on the pressure index.

6. The method according to claim 1, characterized in that, The method further includes: When an attack event is detected, a test report corresponding to the attack event is generated; wherein, the test report includes multiple fields for characterizing attack features and node response behavior, the multiple fields including at least: attack type, hash identifier of related transaction, PoH timestamp, target transaction loss amount, processing time, and processing behavior information of the tested node.

7. The method according to claim 1, characterized in that, The storage of the first execution result, the second execution result, the comparison result, and the identification result includes: The first execution result, the second execution result, the comparison result, and the identification result are stored locally; Calculate the hash values ​​of the first execution result, the second execution result, the comparison result, and the identification result, respectively; Determine the root hash of all hash values ​​and write the root hash into the Solana chain.

8. A testing device for Solana chain nodes, characterized in that, The testing device includes a partitioning module, an execution module, a processing module, and an auditing module; The segmentation module is used to divide multiple transactions in the target test project into multiple transaction clusters, and select multiple candidate transaction clusters for replay from the multiple transaction clusters; The execution module is used to submit the multiple transaction clusters to the node under test in units of clusters, so as to instruct the node under test to execute the transactions according to the cluster-level parallel processing mechanism and return the first execution result corresponding to the multiple transaction clusters; The execution module is further configured to submit the plurality of candidate transaction clusters to the isolation device in units of clusters, so as to instruct the isolation device to replay the plurality of candidate transaction clusters and return the second execution result corresponding to the plurality of candidate transaction clusters; The processing module is configured to receive the first execution result and the second execution result, and compare the consistency between the first execution result and the second execution result to obtain a comparison result; The processing module is further configured to identify attack events based on the first execution result and obtain an identification result; The audit module is used to store the first execution result, the second execution result, the comparison result, and the identification result.

9. A test device for Solana chain nodes, comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method of any one of claims 1 to 7.

10. A computer program product, characterized in that, Includes a computer program / instruction that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images