Notary group cross-chain strategy based on two-stage protocol

Abstract

The invention belongs to the technical field of block chains, and particularly relates to a notarist group cross-chain strategy based on a two-stage protocol, and the strategy comprises the following steps: 1, constructing a cross-chain transaction system model composed of a source chain, a target chain and a notarist group, respectively setting public accounts in the source chain and the target chain, and a transaction pool for managing transaction data is established by the notarist group. 2, a request stage: after a transaction failure is detected, a system enters the request stage, key indexes such as network delay, chain load, a notarist response state, exchange rate fluctuation and a historical failure rate are collected, and a feasibility score value of transaction rollback is calculated through normalization processing and a weighting function; the system generates a dynamic rollback threshold value according to the current environment and compares the dynamic rollback threshold value with the score value, if the score value is lower than the threshold value, it is judged that rollback can be executed, and a rollback stage is entered; otherwise, directly turning to the compensation process. 3, the system constructs an on-chain revocation request according to the original transaction, and monitors whether rollback is successful or not within the set monitoring time; if not, retry is tried, and the compensation process is automatically switched to after the threshold value is exceeded. 4, a compensation stage: the system calculates a compensation amount and pushes the compensation amount to the user in combination with the original transaction amount and the exchange rate change, and in-chain compensation transaction is executed after the user authorizes and confirms the compensation amount; and if no response or rejection exists, the transaction compensation process is terminated.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a notary group cross-chain strategy based on a two-phase protocol, which aims to solve the problems of efficiency and reliability existing in existing cross-chain rollback transactions. Background Art

[0002] Cross-chain transactions have become a critical need in the blockchain ecosystem, but existing mechanisms often employ simple rollback or compensation strategies when transactions fail, lacking adaptability to complex network environments and dynamic market conditions. Traditional approaches often rely on a single factor (such as transaction status or exchange rate fluctuations) to trigger rollbacks, leading to the following problems: frequent and ineffective rollbacks waste resources; ignoring real-time conditions such as network latency and chain load, which can lead to secondary failures; and static decision-making models struggle to cope with market fluctuations and node instability. These issues severely reduce the reliability and efficiency of cross-chain transactions, necessitating an intelligent, dynamic rollback decision-making mechanism.

[0003] The two-phase protocol proposed in this paper addresses these issues through dynamic evaluation and adaptive decision-making. First, a multi-factor weighted objective function is designed to quantify rollback risk by integrating network latency, chain load, node status, exchange rate fluctuations, and historical records to ensure scientific decision-making. Second, a dynamic threshold adjustment mechanism is introduced to optimize trigger conditions based on real-time system load to avoid resource waste. Finally, by pre-assessing risks during the request phase and designing user interactions during the rollback phase, transaction atomicity is ensured while enhancing flexibility. This strategy significantly reduces the invalid rollback rate and automatically switches to compensation mode during periods of significant market fluctuations, achieving efficient fault tolerance for cross-chain transactions. Summary of the Invention

[0004] This paper proposes a notary group cross-chain strategy based on a two-phase protocol, aiming to address the problems of existing cross-chain transaction systems, such as insufficiently intelligent transaction failure handling, severe resource waste, and inflexible user asset compensation mechanisms. By introducing a feasibility assessment process for transaction failures and a dynamic rollback threshold model, this mechanism makes transaction rollback or compensation decisions more scientific and rational, thereby improving the fault tolerance and overall transaction efficiency of the cross-chain system.

[0005] In addition, the present invention also combines factors that are easily affected in cross-chain transactions, such as network latency, chain load, exchange rate fluctuations and other variables, to monitor and dynamically adjust the system status in real time, and proposes a complete indicator system and scoring model, which effectively avoids uncertain risks in extreme markets or high-load environments, and provides stronger stability and robustness for cross-chain infrastructure.

[0006] The technology adopted by the present invention comprises the following steps:

[0007] S1: Construct a cross-chain transaction system consisting of a source chain, a target chain, and a notary group. The source chain serves as the transaction initiator, the target chain as the transaction receiver, and the notary group is responsible for verifying, managing, and coordinating the transaction process. Public accounts are established on both the source and target chains for locking and releasing assets. A transaction pool is established within the notary group system to store transaction credentials, failure records, and transaction status information. The transaction pool and public accounts are jointly maintained by the notary group members. After a transaction is initiated, the system performs asset locking, inventory submission, and verification according to established procedures. If a transaction fails on either side, the failure detection process begins. This process does not immediately trigger compensation or rollback, but instead proceeds to the next stage of request evaluation.

[0008] S2: Request Phase: The main task of the request phase is to determine whether the current system environment is suitable for a rollback operation to avoid secondary failures caused by poor system status. After detecting a cross-chain transaction failure, the system initiates the request phase, which monitors the current environment in multiple dimensions and evaluates the feasibility of a rollback. The main indicators include the following:

[0009] Current average network latency: the average response time of network requests per unit time, representing the communication efficiency of the system;

[0010] Current chain load: reflects the number of transactions currently being processed by the blockchain system. A high value indicates chain congestion and increased risk of rollback.

[0011] Node response status: records the activity status of each participating notary node and the average request response time, indicating the stability of the network service;

[0012] Exchange rate fluctuation range: Statistics on the fluctuation range of cross-chain asset exchange rates within a set window period to assess price change risks;

[0013] Historical Failure Rate: This counts the number of failures for a transaction or user over a certain period of time, and is used to estimate future failure probabilities.

[0014] After normalization, these indicators are calculated using a pre-set weighted objective function to determine the feasibility score for transaction rollback. Simultaneously, a rollback threshold is dynamically generated based on the current system environment. If the score is below the threshold, the system determines that the rollback risk is controllable and enters the rollback phase. Otherwise, compensation procedures are implemented or the transaction is terminated.

[0015] S3: Rollback Phase: After the request phase passes the evaluation, the system enters the rollback phase. The core goal of this phase is to safely and efficiently reverse the failed transaction status and provide remedial measures when necessary. After the evaluation phase determines that a rollback is possible, the system initiates an on-chain rollback transaction operation by the notary group. If the rollback is successful, the transaction status is updated to "rolled back" and the transaction process is terminated. If the rollback fails, the following processing is performed:

[0016] The failure reason is identified, if it is a short-term network problem, a retry mechanism can be set;

[0017] If the retry fails or the failure reason is uncontrollable conditions (such as node exception, chain state disorder, etc.), terminate the rollback process and enter the compensation process;

[0018] The system records the failure reason and adjusts the reputation value of the related node according to the notary group reputation mechanism.

[0019] S4: If the transaction rollback is not feasible or fails, the system sends a compensation plan to the user, including the estimated loss amount and the compensation amount under the current exchange rate. The user can choose the following operations:

[0020] Accept compensation, the system executes the in-chain compensation transaction through the notary group public account;

[0021] Reject compensation, the user can re-initiate the transaction;

[0022] No feedback is given by default, the system marks the transaction as failed and the process is terminated.

[0023] Further, the step S2 specifically comprises the following steps:

[0024] S21: Data collection: In order to accurately evaluate the feasibility and necessity of rolling back the transaction, the present application introduces a rollback transaction objective function based on multi-dimensional index weighted calculation, and immediately collects the following five types of key indicators:

[0025] Network delay: measure the average time required from requesting a transaction to responding to confirmation, reflecting the communication efficiency between chains;

[0026] Chain load: get the total number of transactions in the current transaction pool that are in an incomplete state, indicating the busyness of the chain;

[0027] Notary status: evaluate the activity and response time of each notary node, reflecting the execution ability of the node;

[0028] Exchange rate fluctuation: statistics the fluctuation range of cross-chain asset exchange rate within a set window period, and evaluate the price change risk;

[0029] Historical failure rate: statistics the number of failures of the transaction or the user within a certain period of time, used to predict the future failure probability.

[0030] The above factors are integrated by standardization and weighting to form a rollback transaction feasibility scoring function. The scoring result will be compared with the rollback threshold generated dynamically by the system, so as to assist the system in intelligent decision-making whether to perform rollback operation.

[0031] S22: Data normalization: To ensure the accuracy of the objective function, the following steps are required for calculation and decision making:

[0032] Since different factors have different dimensions, the data needs to be standardized. The min-max normalization method is used to process the collected data separately. The processing formula is shown below:

[0033]

[0034] In the formula, X' is the processing result, X is the original data, and X max and X min are the minimum and maximum values ​​of the indicator respectively.

[0035] S23: Calculation of rollback objective function: The objective function uses a weighted calculation method to quantify the impact of different factors and conduct a comprehensive evaluation. The calculation formula of the objective function rollback feasibility score F is as follows:

[0036] F=ω1·L+ω2·C+ω3·N+ω4·E+ω5·H

[0037] Where F is the rollback feasibility score, which determines whether to execute the rollback transaction; L is the network latency, which indicates the stability of the current network environment; C is the chain load, which reflects the current computing and storage pressure of the blockchain; N is the node status, which measures the reputation and availability of the notary node; E is the exchange rate fluctuation, which affects the economic feasibility of the rollback; H is the historical failure record of the node, which indicates the failure risk of the transaction; ω1, ω2, ω3, ω4, and ω5 are the weights of each factor, indicating their influence on the rollback decision.

[0038] S24: Dynamic rollback threshold calculation: Weight adjustment. Considering the particularity of cross-chain transactions based on blockchain, a single static threshold T and fixed weight value may not be optimal in all transaction scenarios. To solve this problem, a dynamically changing rollback threshold T' is designed and adjusted according to the current system status. The calculation formula for the dynamic rollback threshold T' is as follows:

[0039]

[0040] Where T' is the dynamic rollback threshold, α is the smoothing factor, T is the current rollback threshold, is the basic threshold, L' and C' are the normalized results of network status and chain load.

[0041] S25: Calculate the objective function F value and compare it with the dynamic rollback threshold T'.

[0042] If F <T',则执行回滚;否则,采用交易补偿机制进行补偿并完成交易。

[0043] Furthermore, the step S3 specifically includes the following steps:

[0044] S31: Construct a rollback transaction request: The system constructs the corresponding on-chain revocation operation based on the original transaction record, as shown in Table 1. The construction content includes the original transaction number, transaction timestamp, addresses of both parties to the transaction, notary signature, etc.

[0045] S32: Broadcast and monitoring confirmation: After the transaction is constructed, it is submitted to the chain network and confirmed by the network nodes. The system starts a fixed-length monitoring window to monitor in real time whether the transaction is confirmed successfully.

[0046] If the transaction is confirmed and written into the block within the window period, the system will update the transaction status to "rollback successful" and the transaction process will be terminated;

[0047] If it is not confirmed within the window, the system determines that the transaction rollback has failed.

[0048] S33: Retry and abort strategy after failure: If the rollback fails, the system will execute the following strategy:

[0049] Failure type identification: such as rollback delays caused by transaction pool congestion or chain congestion;

[0050] Set the maximum number of retries N: If a failure occurs, the system will retry and attempt to reconstruct and submit the rollback transaction within a maximum of N retries;

[0051] Complete rollback failure: If the number of retries is exceeded or the failure type is a systemic error (such as a target chain exception), the system will mark the rollback as a failure and enter the compensation process;

[0052] Records and notary reputation adjustment: Information such as failure reasons, number of rollback attempts, and execution nodes are written into the transaction pool, and the reputation of the notary group responsible for the rollback is evaluated and deducted.

[0053] Furthermore, the step S4 specifically includes the following steps:

[0054] S41: Compensation Plan Generation and Delivery: The system retrieves failed transaction records and exchange rate information from the transaction pool, calculates user losses, and automatically generates a compensation plan. Compensation information includes: compensation currency and amount, compensation execution method, and user selectable options.

[0055] S42: User authorization and response processing: The system pushes a compensation confirmation request to the user through the on-chain message service. The user must respond within the time limit:

[0056] If you agree, you need to sign and authorize, and the system will start the compensation transfer process;

[0057] If you choose to re-transact, the original transaction will be invalidated, a new transaction number will be generated, and the transaction preparation process will be re-entered;

[0058] If there is no response within the time limit, the system will consider it as a default waiver of compensation and record the status as "Transaction failed - user did not respond".

[0059] S43: Compensation Transaction Execution and Confirmation: The system initiates a compensation transaction from the notary group's public account and monitors the on-chain confirmation result. If the transaction is successful, the transaction pool status is updated to "Transaction Failed - Compensated". If it fails, up to N retries are performed or manual intervention is required.

[0060] S44: Exception Handling and Credit Accountability: If a user questions the failure of compensation or the incorrect amount of compensation, the system will randomly select a group of notaries not involved in the transaction for audit confirmation. If the system confirms that the compensation is correct and the user still makes a false complaint, this behavior will be recorded and added to the credit system, affecting their subsequent transaction priority. If an incorrect compensation is confirmed, the system will immediately implement compensation correction and punish the responsible notary node.

[0061] The present invention has the following beneficial effects:

[0062] This invention provides an efficient and secure cross-chain rollback transaction mechanism, which comprehensively considers multiple factors such as chain load and network delay to evaluate the necessity of rollback, improves the intelligent response after transaction failure, reduces the resource waste caused by unnecessary rollback operations, and combines a two-stage protocol design to enhance transaction transparency and trust protection through dynamic evaluation and user interaction, with extremely high engineering implementation value. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] The accompanying drawings of the present invention are as follows:

[0064] Figure 1 This is a diagram of the notary group cross-chain transaction model of the present invention;

[0065] Figure 2 This is the cross-chain transaction flow chart of the present invention; DETAILED DESCRIPTION

[0066] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0067] See also Figures 1 and 2 ,like Figure 1 As shown, the preferred embodiment of the present invention provides a model for cross-chain transactions by a notary group. The model mainly includes the following steps to implement cross-chain transactions:

[0068] S1: Create a public account on the source chain and the target chain respectively, set up a transaction pool in the notary group system, and the public account and transaction pool are jointly maintained by the notary group members. The notary group can advance the transaction process based on the transaction number and transaction status saved in the transaction pool; build a cross-chain transaction model consisting of the source chain, the target chain and the notary group.

[0069] Source Chain is the initiator of the transaction and is responsible for transaction application, asset pledge and transaction request.

[0070] The target chain is the receiver and is responsible for confirming transactions, responding to asset receipt and providing feedback.

[0071] The notary group is a collection of independent nodes responsible for cross-chain transaction verification, coordination, rollback and compensation management.

[0072] Public accounts are set up on the source chain and the target chain respectively, and the notary group establishes a transaction pool for storing transaction vouchers to record all process data, status, failure reasons, etc. of the transaction.

[0073] S2: Request phase: The system normalizes real-time data from five dimensions: network latency (L), chain load (C), node status (N), exchange rate fluctuation (E), and historical failure rate (H), and calculates a weighted rollback feasibility score R. If R is lower than the dynamically generated threshold T, a rollback is triggered; otherwise, the process is terminated and the compensation mechanism is initiated.

[0074] S3: Rollback phase: The notary group constructs a reverse transaction containing the original transaction, timestamp and other information and submits it to the blockchain. The system then enters a listening window to monitor the confirmation status. If successful, it is marked as "rolled back". Otherwise, after a limited number of retries, it enters the compensation process and dynamically adjusts the notary node's reputation score.

[0075] S4: Compensation stage: The system automatically generates a compensation plan based on the economic impact of the transaction failure, pushes it to the user for confirmation, and then executes on-chain compensation; if the user refuses or does not respond, the process is terminated. If the compensation fails, it will be retried or transferred to manual processing. The user can raise an objection to trigger a notary audit, which will correct the error after verification or punish malicious complaints to ensure asset protection and fairness.

[0076] Furthermore, the step S2 specifically includes the following steps:

[0077] S21: The source chain user sends a transaction request to the notary group. After verifying their identity, the notary group generates a transaction ID for the transaction request, pushes it along with the transaction request to the transaction pool for storage, and forwards the transaction request to the target chain user. After a transaction failure is triggered, the system collects the following five key metrics: network latency, chain load, node response status, and historical exchange rate failure rate.

[0078] S22: To ensure the accuracy of subsequent calculations, the system standardizes each indicator using the following normalization formula:

[0079]

[0080] S23: After normalizing all indicators, bring them into the multi-dimensional weighted objective function to calculate the current transaction rollback risk score:

[0081] F=ω1·L+ω2·C+ω3·N+ω4·E+ω5·H

[0082] Among them, ω1, ω2, ω3, ω4, and ω5 are the weight values ​​preset by the system, representing the proportion of each indicator in the overall risk assessment.

[0083] S24: The system dynamically generates a rollback threshold based on the current state of the chain, using the following formula:

[0084]

[0085] Where T' is the dynamic rollback threshold, α is the smoothing factor, T is the current rollback threshold, is the basic threshold, L' and C' are the normalized results of network status and chain load.

[0086] S25: Finally, compare F with T': If F <T',表示当前环境适合进行回滚,进入下一阶段;否则跳转至补偿流程S4。

[0087] Furthermore, the step S3 specifically includes the following steps:

[0088] S31: Construct an on-chain rollback request based on the original transaction recorded in the transaction pool. This request includes the transaction number, timestamp, addresses of both parties, notary signature, and a description of the rollback purpose. Once constructed, the system broadcasts this request to the source or target chain.

[0089] Preferably, as shown in Table 1, the rollback request parameters include:

[0090] Table 1: Rollback request parameters

[0091] Parameter Symbol Parameter meaning <![CDATA[ID T ]]> Transaction ID <![CDATA[ID A ]]> Source chain user address <![CDATA[ID B ]]> Target chain user address Sig p ]]> Notary signature Tx Timestamp Ex Rollback purpose description

[0092] S32: The system enters the monitoring state and continuously monitors whether the transaction is successfully confirmed by the chain network within the set time window:

[0093] If the transaction is successfully confirmed, the system will mark the transaction as "rollback successful" and terminate the current process;

[0094] If the timeout is not confirmed, the system will record the failure log and determine whether to enter the rollback and retry mechanism.

[0095] If the failure is caused by short-term chain delay or network jitter, the system will retry up to N times; if the retry limit is exceeded or the failure is caused by a structural error, the system will determine that the rollback has failed and immediately enter the compensation processing phase.

[0096] At the same time, the system will write the failure information into the notary's reputation evaluation module, deduct the reputation value based on factors such as node response delay and signature error, and provide a decision-making basis for future notary group elections.

[0097] Furthermore, the step S4 specifically includes the following steps:

[0098] S41: Read the failed transaction data recorded in the transaction pool, including transaction amount, timestamp, currency, asset type, target chain account, etc. At the same time, by connecting to the trusted price oracle module, obtain the exchange rate at the time of transaction failure and the current real-time exchange rate, and calculate the compensation amount.

[0099] Based on this, the system generates a compensation plan, which details: the currency and amount of compensation that users can obtain, the initiator of the compensation and the method of distribution, and clearly states that users need to confirm and respond to the plan within a certain time window.

[0100] S42: If the user agrees to the plan, they must authorize the compensation transaction through digital signature. After receiving the user's signature, the system immediately executes the intra-chain transfer and updates the transaction pool status to "Transaction Failed - Compensated".

[0101] If the user actively refuses compensation, the system will mark the transaction as "User refuses compensation" and allow the user to re-initiate the transaction process; if the user does not respond for a long time, the system will assume that the user has waived the right to compensation and mark it as "Transaction failed - user did not respond".

[0102] S43: If the compensation transaction fails to execute on the chain, the system can start a retry mechanism up to N times. If it still fails, it will be handed over to the administrator for intervention or call the backup notary group compensation execution module.

[0103] In case of compensation disputes, the system supports users to submit review requests. The system will call other node groups that did not participate in the transaction to conduct an on-chain audit of the original transaction and compensation plan.

[0104] If an erroneous compensation is confirmed, the system will immediately correct it and penalize the responsible node;

[0105] If the user's appeal is confirmed to be invalid, their address will be placed on the grey list, restricting future transaction permissions and response priority.

[0106] Through the mechanism, the application not only protects the legal rights and interests of the user when the transaction fails, but also enhances the identification and response ability of the system to abnormal behaviors, and ensures the stability, fairness and sustainability of the overall cross-chain network operation.

[0107] While embodiments of the application have been shown and described, it is to be understood that the embodiments described are merely divergences of the principles and specific embodiments of the application and that numerous modifications, changes, substitutions, and alterations can be made thereto without departing from the spirit and scope of the application as defined by the appended claims and their equivalents.

Claims

1. A notary group cross-chain strategy based on a two-phase protocol, characterized by: The method is implemented by a cross-chain transaction system executed by a notary group, including the following steps: S1: Construct a transaction model composed of a source chain, a target chain, and a notary group as shown in Figure 1. In this model, the source chain is the initiator of the transaction, and the target chain is the recipient of the transaction; create a public account on the source chain and the target chain respectively, and at the same time set up a transaction pool for storing transaction voucher information; the transaction execution process of the cross-chain transaction system includes an asset locking stage where the source chain completes the pledge of transaction assets through the public account, verification by the notary group to sign and reach a consensus on the transaction data, target chain verification where the target chain receives and verifies the transaction data and then feedbacks the asset reception result, and exception handling where when the system detects transaction timeout or failure, it automatically interrupts the current process and triggers a rollback feasibility evaluation mechanism; S2: Request stage: After detecting a transaction failure, instead of immediately performing a rollback, it enters the request stage. By normalizing the real-time data of five dimensions: network latency (L), chain load (C), node status (N), exchange rate fluctuation (E), and historical failure rate (H), and calculating the rollback feasibility score F through weighted calculation. If F is lower than the dynamically generated threshold T', a rollback is triggered; otherwise, the process is terminated and transferred to the compensation mechanism; S3: Rollback stage: The notary group constructs a reverse transaction and submits it to the blockchain, and then the system enters a listening window period to monitor the confirmation status; if successful, it is marked as "rolled back", otherwise, after a limited number of retries, it is transferred to the compensation process, and at the same time, the reputation score of the notary node is dynamically adjusted to optimize subsequent consensus participation; S4: Compensation stage: Automatically generate a compensation plan according to the economic impact of the transaction failure, push it to the user for confirmation and then execute on-chain compensation; if the user refuses or does not respond, the process is terminated. If the compensation fails, retry or transfer to manual processing. The user can raise an objection to trigger a notary audit. After verification, correct the error or punish malicious complaints to ensure asset protection and fairness.

2. The method according to claim 1, wherein: The calculation of the objective function in step S2 further includes: S21: Based on the key factors affecting the rollback transaction, construct a rollback transaction objective function, and obtain the rollback feasibility score F by calculating the normalized values of five dynamic factors: network latency (L), chain load (C), node status (N), exchange rate fluctuation (E), and historical failure record (H) through weighted calculation. The calculation formula is: F = ω1·L + ω2·C + ω3·N + ω4·E + ω5·H F represents the rollback feasibility score; L represents network latency; C represents chain load; N represents node status; E represents exchange rate fluctuation; H represents the historical failure record of this node; ω1, ω2, ω3, ω4, ω5 are the weights of each factor, indicating the degree of their influence on the rollback decision. S22: Dynamically adjust the rollback threshold T', and calculate it in real time according to the network state and chain load: Where T' is the dynamic rollback threshold, α is the smoothing factor, T is the current rollback threshold, is the basic threshold, L' and C' are the normalized results of network status and chain load. S23: Calculate the value of the objective function F and compare it with the dynamic rollback threshold T'. If F < T', perform a rollback; otherwise, use the transaction compensation mechanism for compensation and complete the transaction.

3. The method according to claim 1, wherein: The request stage of step S3 specifically includes: S31: Constructing a rollback transaction request: The system constructs the transaction based on the original transaction record and submits it to the blockchain network for confirmation by network nodes. The system initiates a fixed-length listening window to monitor in real time whether the transaction has been successfully confirmed. If the transaction is confirmed and written into the block within the window period, the system will update the transaction status to "rollback successful" and the transaction process will be terminated; If it is not confirmed within the window, the system determines that the transaction rollback has failed. S32: Retry and abort strategy after failure: If the rollback fails, the system will execute the following strategy: Failure type identification: such as rollback delays caused by transaction pool congestion or chain congestion; Set the maximum number of retries N: If a retry fails, the system will try to reconstruct and submit the rollback transaction within a maximum of N retries; Complete rollback failure: If the number of retries is exceeded or the failure type is a systemic error (such as a target chain exception), the system will mark the rollback as a failure and enter the compensation process; Records and notary reputation adjustment: Information such as failure reasons, number of rollback attempts, and execution nodes are written into the transaction pool, and the reputation of the notary group responsible for the rollback is evaluated and deducted.

4. The method according to claim 1, wherein: The rollback phase of step S4 further includes: S41: The system obtains failed transaction records and exchange rate information from the trading pool, calculates the user's losses, and automatically generates a compensation plan. The system pushes a compensation confirmation request to the user via the on-chain messaging service. The user must respond within the time limit: If you agree, you need to sign and authorize, and the system will start the compensation transfer process; If you choose to re-transact, the original transaction will be invalidated, a new transaction number will be generated, and the transaction preparation process will be re-entered; If there is no response within the time limit, the system will consider it as a default waiver of compensation and record the status as "Transaction failed - user did not respond". S42: Initiate a compensation transaction from the notary group's public account and monitor the on-chain confirmation result. If the transaction is successful, the transaction pool status is updated to "Transaction Failed - Compensated". If it fails, retry up to N times or submit for manual intervention. S43: If a user questions the compensation failure or the amount is incorrect, the system will select a notary group not involved in the transaction for verification. If the system confirms that the compensation is correct and the user still makes a false complaint, this behavior will be recorded and added to the reputation system, affecting their subsequent transaction priority. If the compensation is confirmed to be incorrect, the system will immediately implement compensation correction and punish the responsible notary node.

Images