Automatic right certificate exchange method for resisting sandwich attack on alliance chain

Abstract

The invention relates to the field of block chains, and discloses an anti-sandwich attack automatic right attestation exchange method on an alliance chain, which is used for solving the problem that when an automatic right attestation exchange protocol is easily subjected to sandwich attack due to the fact that the transaction price is easily changed by a prepositive transaction, a consensus protocol on a block chain needs to be reconstructed again, and the security of the automatic right attestation exchange protocol is influenced. The method comprises the following steps: in an exchange window, collecting a transaction request of a user, carrying out validity verification, calculating an exchange result of each transaction and a new state of a right proof pool through a covalence formula according to a current state of the right proof pool and transaction request data of the user, and carrying out transaction request verification on the transaction request data of the user; and verifying the transaction result of the under-chain calculation unit and related data to obtain the transaction result passing the on-chain verification, and updating the state of the right proof pool and the user account, thereby effectively achieving the effect of resisting sandwich attack, maintaining the compatibility with the existing block chain, and reducing the on-chain overhead.

Description

Technical Field

[0001] The present invention relates to the field of blockchain, and more specifically to a method for automatic rights proof exchange on a consortium chain that is resistant to sandwich attacks. Background Art

[0002] The automatic proof-of-rights exchange protocol is a proof-of-rights exchange method implemented by a smart contract. When exchanging proofs of rights, the protocol can dynamically calculate the exchange ratio of the two rights based on the number of rights exchanged and the status of the proof-of-rights pool, using the calculation method predefined in the smart contract, and the exchange can be completed without the need for a trusted third party.

[0003] The pricing model of Uniswap, the most popular automatic proof-of-rights exchange protocol, will cause pre-trading against the victim's transactions, increasing the victim's unexpected slippage. The attack can also be combined with post-trading to allow the attacker to obtain attack benefits from the transaction spread.

[0004] For example, the invention patent announcement number is: CN117714028A, which announces a resource exchange method and device, electronic device and storage medium of a consortium chain, including: obtaining a user's resource exchange request, the resource exchange request includes: resource exchange information and ciphertext data, selecting an endorsement node from a preset consortium chain, and obtaining a selected endorsement node. Perform homomorphic computing operations on the resource exchange information and ciphertext data through the selected endorsement node and the preset target homomorphic encryption model to obtain execution result data, the execution result data includes: ciphertext execution result and execution proof data, and verify the ciphertext execution result and execution proof data through the preset verification node to obtain the verification result. The verification node is an endorsement node selected from the consortium chain other than the selected endorsement node, and the resource exchange is completed according to the verification result and the resource exchange request. The embodiment of the present application can reduce the computational overhead of homomorphic computing and thus improve computer performance.

[0005] For example, the invention patent announcement with announcement number: CN109257180A discloses a method and device for storing intellectual property documents based on blockchain, including: the user terminal uses the blockchain system on the storage system platform, combined with multi-signature technology and trusted timestamp signature technology, to encrypt and store the intellectual property documents during the storage and registration process, ensuring that the intellectual property documents will not be leaked during storage and registration, and using the tamper-proof nature of the blockchain system to provide users with proof of rights.

[0006] However, in the process of implementing the technical solution of the invention in the embodiments of the present application, the present application found that the above technology has at least the following technical problems:

[0007] In order to solve the problem that the automatic proof-of-rights exchange protocol is easily affected by the previous transaction changing the transaction price and thus suffering from sandwich attacks, previous solutions are mainly divided into two categories. One is to hide transaction information through cryptographic commitments and other methods, so that attackers cannot conduct targeted attacks by monitoring pending transactions in the memory pool. This method requires multiple on-chain interactions, which will bring additional transaction costs to Jiaotong University. The second is to sort transactions fairly through the election committee and consensus within the committee, so that attackers cannot manipulate the transaction order and thus cannot obtain controllable attack results. The disadvantage of this method is that it requires the reconstruction of the consensus protocol on the blockchain and is not compatible with some existing representative blockchains. Summary of the invention

[0008] In order to overcome the above-mentioned defects of the prior art, the present invention provides a method for automatic rights proof exchange on a consortium chain that is resistant to sandwich attacks, so as to solve the problems existing in the above-mentioned background technology.

[0009] To achieve the above object, the present invention provides the following technical solutions:

[0010] A method for automatic rights proof exchange on a consortium chain that is resistant to sandwich attacks, the consortium chain comprising an off-chain aggregation unit, an off-chain computing unit, an off-chain submission unit, an on-chain verification unit and an on-chain execution unit, comprising the following steps: Step 1: within an exchange window, collect user transaction requests and verify their legitimacy; Step 2: in the off-chain computing unit, calculate the exchange result of each transaction and the new state of the rights proof pool by the same price formula according to the current state of the rights proof pool and the user's transaction request data; Step 3: verify the transaction results and related data of the off-chain computing unit to obtain the transaction results that have passed the on-chain verification; Step 4: according to the transaction results passed by the on-chain verification unit, update the status of the rights proof pool and the user account through the on-chain execution unit.

[0011] Preferably, the steps of collecting transaction requests from users and verifying their legitimacy within an exchange window are as follows: taking 1 / 2 of the block generation time after the latest block is generated as a fixed exchange window period; allowing users to submit exchange requests for proof of rights within each exchange window period, and at the end of the exchange window, the system no longer accepts new requests and enters the data processing stage; during the collection period, the off-chain aggregation unit receives transaction requests submitted by users and strictly verifies the legitimacy of each request; after the collection period ends, the off-chain aggregation unit counts and aggregates all transaction requests by category, and after the off-chain aggregation unit summarizes all transaction requests, it submits them to the off-chain calculation unit for subsequent exchange calculations.

[0012] Preferably, the strict verification of the legitimacy of each request includes custody asset verification and signature legitimacy verification; custody asset verification is used to check whether the custody assets in the user account are sufficient, and the off-chain aggregation unit will check whether the user account holds a sufficient number of rights proof X or rights proof Y; signature legitimacy verification is used to verify whether the signature of the transaction request submitted by the user is correct, and the signature of the transaction request is verified using the user's public key. If the signatures match, it is deemed legal.

[0013] Preferably, the off-chain aggregation unit counts and aggregates all transaction requests by category as follows: transactions of exchanging certificate X for certificate Y: record all users' requests to exchange certificate X and exchange certificate Y; transactions of exchanging certificate Y for certificate X: record all users' requests to exchange certificate Y and exchange certificate X. Including m transactions of exchanging certificate X for certificate Y, the number of exchanged certificate X is (δx1 in ,δx2 in , ..., δx m in ). And including n proof of right Y for proof of right X transactions, the number of proof of right Y exchanged is (δy1 in ,δy2 in , ..., δy n in ).

[0014] Preferably, the step of calculating the exchange result of each transaction and the new state of the rights proof pool by the same price formula is as follows: the off-chain computing unit reads the current state of the rights proof pool from the latest block, records the book amount of the two rights proofs, and records it as (x book ,y book ), where x book represents the number of rights certificates X in the rights certificate pool, y book Represents the number of rights proof Y in the rights proof pool; the off-chain computing unit calculates the specific exchange quantity of each transaction through the same price formula based on the current status of the rights proof pool and the user's transaction request; after calculating the actual exchange quantity of each transaction, the off-chain computing unit updates the book quantity of the rights proof pool, and the method to obtain the new status after the transaction is completed is

[0015] Preferably, the same price formula is where δx j in with δy j in are the number of rights certificates X and Y exchanged in the transaction request, respectively. and They are the number of rights certificates X and Y exchanged in the transaction request respectively.

[0016] Preferably, the actual exchange quantity of each transaction includes: for a transaction in which the right certificate X is exchanged for the right certificate Y, the number of the exchanged right certificates Y corresponding to the exchanged right certificates X in each transaction is calculated, and recorded as (δy1 out ,δy2 out , ..., δy m out ); For transactions where proof of right Y is exchanged for proof of right X, the number of proof of right X that is exchanged for the proof of right Y in each transaction is calculated, which is recorded as (δx1 out ,δx2 out ,…,δx n out ).

[0017] Preferably, the transaction results and related data of the off-chain computing unit are verified to obtain the transaction results that have passed the on-chain verification. The steps are as follows: all data completed by the off-chain computing unit are sent to the smart contract through the off-chain submission unit, and all data include the number of swap-out rights certificates requested by the user's transaction, the calculated swap-in number, and the user's transaction signature data; the submitted transaction is verified by the on-chain verification unit in the smart contract; if all verifications are passed, the on-chain verification unit confirms the legitimacy of the transaction data, and the transaction enters the state change stage.

[0018] Preferably, the steps of verifying the submitted transaction through the on-chain verification unit in the smart contract are: checking the signature of each transaction through the on-chain verification unit to ensure that the request comes from a legitimate user; verifying through the on-chain verification unit whether the status of the proof-of-rights pool before and after the transaction meets the expected formula constraints, that is, the total assets in the pool remain unchanged; and verifying the consistency of the price of each transaction through the on-chain verification unit.

[0019] Preferably, the step of updating the status of the rights proof pool and the user account according to the transaction results passed by the on-chain verification unit is: changing the status of the users participating in the transaction in the rights proof pool according to the transaction results passed by the on-chain verification unit; and updating the book quantity of the rights proof pool through the on-chain execution unit according to the transaction results.

[0020] One or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages:

[0021] 1. Collect user transaction requests and verify their legitimacy within an exchange window. In blockchain systems, on-chain operations are usually resource-intensive and costly. By verifying the legitimacy of transactions off-chain, the number of invalid transaction requests on the chain can be reduced, thereby saving gas fees and computing resources; by completing preliminary screening and verification in the collection phase, subsequent calculations and status update processes can focus on valid transaction requests, reducing unnecessary exception handling logic, and making the entire system process clearer and more concise.

[0022] 2. In the off-chain computing unit, according to the current state of the proof-of-rights pool and the user's transaction request data, the exchange result of each transaction and the new state of the proof-of-rights pool are calculated through the same price formula. In the blockchain system, on-chain calculations usually consume high gas fees and computing resources. By transferring complex computing tasks to the off-chain, the system can significantly reduce the computing costs on the chain, and only necessary data verification and recording are required on the chain, thereby reducing transaction costs and improving economic efficiency; the same price formula can dynamically adjust the transaction ratio according to the current state of the proof-of-rights pool (that is, the number of proofs of rights X and Y in the pool) to reflect changes in market supply and demand. This dynamic pricing mechanism ensures that each transaction is calculated based on the current market status, ensures the fairness and rationality of transactions, and avoids arbitrage or market imbalances caused by price rigidity.

[0023] 3. Verify the transaction results and related data of the off-chain computing unit to obtain the transaction results that have passed the on-chain verification. The purpose of on-chain verification is to ensure the authenticity and non-tamperability of the off-chain computing results. Even though the off-chain computing efficiency is higher, only the data that has been verified on the chain can be officially recorded on the blockchain, which ensures the security of the data and makes the transaction data tamper-resistant, in line with the decentralized trust mechanism of the blockchain; through the division of labor between off-chain computing and on-chain verification, the system can move the heavy computing tasks to the off-chain, and only execute the verification logic on the chain, consuming less on-chain resources. On-chain verification only needs to check whether the key parameters meet the rules, and there is no need to repeat the complex calculations off the chain, so it can effectively save Gas fees and reduce the transaction costs of users.

[0024] 4. Update the status of the rights proof pool and user account according to the transaction results passed by the on-chain verification unit. The transaction results that have passed the on-chain verification represent verified and reliable data. Updating the status of the rights proof pool and user account according to the verification results ensures that the account status of all participants and the balance of the rights proof pool are consistent with the on-chain records, achieving the final consistency of the data and avoiding data deviations caused by erroneous or unverified transactions; since the results of each transaction will be reflected in the rights proof pool and user account through status updates, each change in the system status has a corresponding blockchain record. In this way, the historical status of all transactions can be traced and audited, which is convenient for supervision or system operation and maintenance, and improves the compliance and audit capabilities of the entire system. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 An overall flow chart of a method for automatic rights proof exchange on a consortium chain that is resistant to sandwich attacks provided in an embodiment of the present application.

[0026] Figure 2 A unit flow chart of a method for automatic rights proof exchange on a consortium chain that is resistant to sandwich attacks provided in an embodiment of the present application.

[0027] Figure 3 A graph showing test results of the time consumption change of an exchange result of a method for automatic rights proof exchange on a consortium chain that is resistant to sandwich attacks provided in an embodiment of the present application.

[0028] Figure 4 A cost comparison chart of a method for automatic rights proof exchange on a consortium chain that is resistant to sandwich attacks provided in an embodiment of the present application. DETAILED DESCRIPTION

[0029] The technical solution of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the present invention. In addition, the forms of the various structures recorded in the following implementation modes are merely illustrative. The method for automatic exchange of rights certificates on a consortium chain that is resistant to sandwich attacks involved in the present invention is not limited to the various structures recorded in the following implementation modes. All other implementation modes obtained by ordinary technicians in this field without making creative work belong to the scope of protection of the present invention.

[0030] The present invention provides a method for automatic rights proof exchange on a consortium chain that resists sandwich attacks. The consortium chain includes an off-chain aggregation unit, an off-chain calculation unit, an off-chain submission unit, an on-chain verification unit, and an on-chain execution unit, including the following steps:

[0031] Step 1: Within an exchange window, collect user transaction requests and verify their legitimacy, preparing for subsequent calculation and verification;

[0032] An exchange window refers to a pre-set fixed time period during which the system collects all transaction requests submitted by users and verifies their legitimacy. During the validity period of each exchange window, users can submit exchange requests for proof of rights; when the exchange window ends, the system will stop receiving new requests and process the collected request data in a unified manner to prepare for the next off-chain calculation stage. This "exchange window" design can process transactions in batches and improve the processing efficiency of the system.

[0033] In this embodiment, it should be specifically explained that within an exchange window, the steps of collecting user transaction requests and performing legitimacy verification are as follows:

[0034] Set the duration of each exchange window, usually 1 / 2 of the block generation time after the latest block generation is a fixed exchange window period. For example, if the block generation interval is 10 seconds, the exchange window time is 5 seconds;

[0035] In each exchange window, users are allowed to submit exchange requests for proof of rights. When the exchange window ends, the system will no longer accept new requests and enter the data processing stage;

[0036] During the collection period, if Figure 2 As shown, the off-chain aggregation unit receives transaction requests submitted by users and strictly verifies the legitimacy of each request;

[0037] After the collection period, the off-chain aggregation unit will count and aggregate all transaction requests by category. After summarizing all transaction requests, the off-chain aggregation unit will submit them to the off-chain calculation unit for subsequent exchange calculations.

[0038] Proof of Rights is a blockchain-based digital certificate used to prove a user's specific rights or assets in the system. Proof of Rights can represent the ownership, right to use, or other specific rights of a digital asset, and it can be exchanged or transferred between users. Each user's Proof of Rights is managed and verified through smart contracts on the blockchain to ensure the authenticity and validity of all transactions while preventing tampering or forgery.

[0039] In this embodiment, it should be specifically noted that the strict verification of the legitimacy of each request includes the verification of the escrow assets and the verification of the legitimacy of the signature;

[0040] Custodial asset verification is used to check whether the custodial assets in the user's account are sufficient to ensure that the exchange request submitted by the user can be met. Specifically, the off-chain aggregation unit will check whether the user's account holds a sufficient number of proof of rights X or proof of rights Y;

[0041] Signature legitimacy verification is used to verify whether the signature of the transaction request submitted by the user is correct and ensure that the transaction request is indeed initiated by the user himself. This process uses the user's public key to verify the signature of the transaction request. If the signature matches, it is considered legal.

[0042] In this embodiment, it should be specifically explained that the off-chain aggregation unit counts and aggregates all transaction requests by category in the following steps:

[0043] Transactions of exchanging proof X for proof Y: Record all requests from users to exchange proof X for proof Y. Assume that there are m such transactions, and the number of proofs X exchanged is (δx1 in ,δx2 in ,…,δx m in );

[0044] Transactions of exchanging proof of right Y for proof of right X: Record all requests of users to exchange proof of right Y for proof of right X. Assume that there are n such transactions in total, and the number of proof of right Y exchanged is (δy1 in ,δy2 in , ..., δy n in ).

[0045] Step 2: In the off-chain computing unit, based on the current state of the rights proof pool and the user's transaction request data, the exchange result of each transaction and the new state of the rights proof pool are calculated using the same price formula;

[0046] The Proof of Rights pool is a virtual pool in the blockchain system that is used to centrally manage and record the total amount and distribution of Proof of Rights held by all users in the system. It is equivalent to an asset reserve that stores the current balance status of different types of Proof of Rights (for example, the number of Proof of Rights X and Proof of Rights Y) and is updated based on the user's transaction request. When a user initiates a request to exchange Proof of Rights, the off-chain computing unit will refer to the current status in the Proof of Rights pool, calculate the specific exchange results of each transaction, and adjust the balance in the Proof of Rights pool accordingly to ensure the fairness and consistency of the transaction.

[0047] The same price formula is a mathematical formula used to calculate the equivalent conversion relationship between two proofs of rights during the exchange process. In the proof of rights exchange system, the same price formula dynamically determines the exchange ratio or price of each transaction based on the current balance status of the two proofs of rights in the proof of rights pool (such as the number of proofs of rights X and proofs of rights Y) to ensure that each transaction is fair and reasonable. The formula will automatically adjust as the number of proofs of rights in the pool changes, thereby reflecting the dynamic changes in the supply and demand relationship, so that the exchange ratio between the two proofs of rights during the exchange process is always in a balanced state.

[0048] In this embodiment, it should be specifically explained that the steps for calculating the exchange result of each transaction and the new state of the rights proof pool by the same price formula are:

[0049] The off-chain computing unit reads the current state of the proof-of-rights pool from the latest block and records the book value of the two proofs of rights, recorded as (x book ,y book ), where x book represents the number of rights certificates X in the rights certificate pool, y book Indicates the number of rights certificates Y in the rights certificate pool;

[0050] The off-chain computing unit calculates the specific exchange quantity of each transaction based on the current status of the proof-of-rights pool and the user's transaction request through the same price formula. The same price formula is: where δx j in with δy j in are the number of rights certificates X and Y exchanged in the transaction request, respectively. and They are the number of exchange-in rights proof X and exchange-in rights proof Y in the transaction request. Through the above formula, the off-chain computing unit calculates the actual exchange-in quantity of each transaction;

[0051] After the calculation is completed, the off-chain computing unit updates the book value of the rights proof pool. The method to obtain the new status after the transaction is completed is as follows: The above formula represents the change in the number of the two types of proofs of rights in the proof of rights pool after all transactions have been processed.

[0052] In this embodiment, it should be specifically explained that the actual exchange quantity of each transaction includes, for the transaction of exchanging right certificate X for right certificate Y, calculating the number of exchanged right certificates Y corresponding to the exchanged right certificate X in each transaction, recorded as (δy1 out ,δy2 out , ..., δy m out ); For transactions where proof of right Y is exchanged for proof of right X, the number of proof of right X that is exchanged for the proof of right Y in each transaction is calculated, which is recorded as (δx1 out ,δx2 out ,…,δx n out ).

[0053] Step 3: Verify the transaction results and related data of the off-chain computing unit to obtain the transaction results that have passed the on-chain verification to ensure the legitimacy of the transaction and data consistency;

[0054] In this embodiment, it should be specifically explained that the transaction results and related data of the off-chain computing unit are verified to obtain the transaction results that have passed the on-chain verification in the following steps:

[0055] All data completed by the off-chain computing unit is sent to the smart contract through the off-chain submission unit. All data includes the number of swap-out rights certificates requested by the user transaction (δx1 in ,δx2 in , ..., δx m in ) and (δy1 in ,δy2 in , ..., δy n in ), the calculated swap-in quantity (δy1 out ,δy2 out , ..., δy m out ) and (δx1 out ,δx2 out , ..., δx n out ) and the user's transaction signature data (σ1, σ2, ... σ m+n );

[0056] Verify the submitted transaction through the on-chain verification unit in the smart contract;

[0057] If all verifications pass, the on-chain verification unit confirms the legitimacy of the transaction data and the transaction enters the state change phase.

[0058] A smart contract is a self-executing code deployed on a blockchain that defines logic and rules that are automatically executed when certain conditions are met. Smart contracts act as a "referee" in the trading system, receiving and verifying data submitted off-chain, and automatically executing transactions, updating account status, allocating assets, and other operations according to pre-set rules. Because the code and execution results of smart contracts are public and cannot be tampered with, all participants can trust that it will run according to the rules, ensuring the transparency and security of the system. In this method, the smart contract is responsible for receiving transaction data submitted by the off-chain computing unit, verifying it, and updating the proof-of-rights pool and the user's account status after verification.

[0059] In this embodiment, it should be specifically explained that the steps for verifying the submitted transaction through the on-chain verification unit in the smart contract are:

[0060] The signature of each transaction is checked by an on-chain verification unit to ensure that the request is indeed from a legitimate user;

[0061] Verify through the on-chain verification unit whether the status of the proof-of-rights pool before and after the transaction meets the expected formula constraints, that is, the total assets in the pool remain unchanged;

[0062] The price consistency of each transaction is verified through the on-chain verification unit to ensure that the transaction is conducted under a fair pricing mechanism.

[0063] Step 4: Based on the transaction results passed by the on-chain verification unit, the status of the rights proof pool and user account is updated through the on-chain execution unit;

[0064] In this embodiment, it should be specifically explained that, according to the transaction results passed by the on-chain verification unit, the steps for updating the status of the rights proof pool and the user account through the on-chain execution unit are:

[0065] According to the transaction results passed by the on-chain verification unit, the status of the user participating in the transaction in the rights proof pool is changed. For example, the number of rights proofs in the user account is adjusted to complete the record of the number of swaps in and out:

[0066] According to the transaction results, the book value of the rights proof pool is updated through the on-chain execution unit, that is, (x′ book , y′ book )Write the proof-of-rights pool status on-chain to ensure the latest asset quantity in the pool.

[0067] After specific actual experiments, the off-chain part used C++ language to implement the same price formula, and tested the changes in the time consumption for calculating the exchange results as the number of transactions included in the aggregated transaction increased. Figure 3 As shown, the horizontal axis represents the number of exchanges, and the vertical axis represents the off-chain computing delay.

[0068] The on-chain part uses Solidity language to implement smart contracts. The on-chain costs (in terms of Gas) incurred when testing different numbers of users on the Ganache test chain are compared with the Gas costs of other existing solutions, such as Figure 4 As shown, the horizontal axis represents the number of exchanges, and the vertical axis represents the computational consumption expressed in Gas.

[0069] Compared with the existing technology, the performance indicators of this method are improved by reducing the off-chain time of a single transaction by 3 orders of magnitude and increasing the maximum throughput by 22% to 70%.

[0070] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

[0071] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A method for automatic rights proof exchange on a consortium chain that resists sandwich attacks, characterized in that: The alliance chain includes an off-chain aggregation unit, an off-chain calculation unit, an off-chain submission unit, an on-chain verification unit, and an on-chain execution unit, including the following steps: Step 1: Collect user transaction requests and verify their legitimacy within an exchange window; Step 2: In the off-chain computing unit, based on the current state of the rights proof pool and the user’s transaction request data, the exchange result of each transaction and the new state of the rights proof pool are calculated using the same price formula; Step 3: Verify the transaction results and related data of the off-chain computing unit to obtain the transaction results that have passed the on-chain verification; Step 4: Based on the transaction results passed by the on-chain verification unit, the status of the rights proof pool and user account is updated through the on-chain execution unit.

2. According to claim 1, the method for automatic rights proof exchange on a consortium chain that resists sandwich attacks is characterized by: The steps of collecting user transaction requests and verifying their legitimacy within an exchange window are as follows: The fixed exchange window period is 1 / 2 of the block generation time after the latest block generation; During each exchange window period, users are allowed to submit exchange requests for proof of rights. When the exchange window ends, the system will no longer accept new requests and enter the data processing stage. During the collection period, the off-chain aggregation unit receives transaction requests submitted by users and strictly verifies the legitimacy of each request; After the collection period, the off-chain aggregation unit will count and aggregate all transaction requests by category. After summarizing all transaction requests, the off-chain aggregation unit will submit them to the off-chain calculation unit for subsequent exchange calculations.

3. According to claim 2, a method for automatic rights proof exchange on a consortium chain that resists sandwich attacks is characterized in that: The strict verification of the legitimacy of each request includes the verification of the escrow assets and the verification of the legitimacy of the signature; Custody asset verification is used to check whether the custody assets in the user account are sufficient. The off-chain aggregation unit will check whether the user account holds a sufficient number of rights proof X or rights proof Y; Signature legitimacy verification is used to verify whether the signature of the transaction request submitted by the user is correct. The signature of the transaction request is verified using the user's public key. If the signatures match, it is considered legal.

4. According to claim 2, a method for automatic rights proof exchange on a consortium chain that resists sandwich attacks is characterized in that: The off-chain aggregation unit performs statistics and aggregation of all transaction requests by category as follows: Transactions of exchanging proof of rights X for proof of rights Y: Record all requests of users to exchange proof of rights X and proof of rights Y; including m transactions of exchanging proof of rights X for proof of rights Y, the number of proof of rights X exchanged is (δx1 in ,δx2 in ,...,δx m in ). Proof of Rights Y for Proof of Rights X: Record all user requests to swap out Proof of Rights Y and swap in Proof of Rights X. This includes n Proof of Rights Y for Proof of Rights X transactions, and the number of Proof of Rights Y swapped out is (δy1 in ,δy2 in ,...,δy n in ).

5. The method for automatic rights proof exchange on a consortium chain that resists sandwich attacks according to claim 1 is characterized by: The steps for calculating the exchange result of each transaction and the new state of the rights proof pool by the same price formula are: The off-chain computing unit reads the current state of the proof-of-rights pool from the latest block and records the book value of the two proofs of rights, recorded as (x book ,y book ), where x book represents the number of rights certificates X in the rights certificate pool, y book Indicates the number of rights certificates Y in the rights certificate pool; The off-chain computing unit calculates the specific exchange quantity of each transaction through the same price formula based on the current status of the proof-of-rights pool and the user's transaction request; After calculating the actual amount of each transaction, the off-chain computing unit updates the book value of the rights proof pool. The method to obtain the new state after the transaction is completed is as follows:

6. The method for automatic rights proof exchange on a consortium chain that resists sandwich attacks according to claim 5 is characterized by: The same price formula is 7. The method for automatic rights proof exchange on a consortium chain that resists sandwich attacks according to claim 5 is characterized by: The actual swap-in quantity for each transaction includes: For transactions where proof X is exchanged for proof Y, calculate the number of proofs Y that are exchanged for the corresponding proof X in each transaction, denoted as (δy1 out ,δy2 out ,...,δy m out ); For transactions where proof of right Y is exchanged for proof of right X, the number of proof of right X that is exchanged for the corresponding proof of right Y in each transaction is calculated, which is recorded as (δx1 out ,δx2 out ,...,δx n out ).

8. The method for automatic rights proof exchange on a consortium chain that resists sandwich attacks according to claim 1 is characterized in that: The steps of verifying the transaction results and related data of the off-chain computing unit to obtain the transaction results that have passed the on-chain verification are as follows: All data completed by the off-chain computing unit is sent to the smart contract through the off-chain submission unit. All data includes the number of rights certificates for swap-out requested by the user, the calculated number of swap-in, and the user's transaction signature data; Verify the submitted transaction through the on-chain verification unit in the smart contract; If all verifications pass, the on-chain verification unit confirms the legitimacy of the transaction data and the transaction enters the state change phase.

9. The method for automatic rights proof exchange on a consortium chain that resists sandwich attacks according to claim 8 is characterized in that: The steps of verifying the submitted transaction through the on-chain verification unit in the smart contract are: Check the signature of each transaction through the on-chain verification unit to ensure that the request comes from a legitimate user; Verify through the on-chain verification unit whether the status of the proof-of-rights pool before and after the transaction meets the expected formula constraints, that is, the total assets in the pool remain unchanged; The price consistency of each transaction is verified by the on-chain verification unit.

10. The method for automatic rights proof exchange on a consortium chain that resists sandwich attacks according to claim 1 is characterized in that: The steps of updating the status of the rights proof pool and the user account through the on-chain execution unit according to the transaction results passed by the on-chain verification unit are as follows: According to the transaction results passed by the on-chain verification unit, the status of the user participating in the transaction in the rights proof pool is changed; Based on the transaction results, the book value of the rights proof pool is updated through the on-chain execution unit.

Images