Cross-Roollup transaction method and device based on native chain

Abstract

The invention provides a cross-Roollup transaction method and device based on a native chain, and the method comprises the steps: a user side transmits a single first transaction to a smart contract of a transmitting party, and the smart contract of the transmitting party executes the first transaction, and generates a corresponding second transaction which needs to be executed in a smart contract of a receiving party; the sender Rollup waits to aggregate a plurality of first transactions for batch execution, generates a plurality of corresponding second transactions and stores the second transactions on the native chain; the sender Roollup verifies the validity of each second transaction on a native chain; and the receiver Rollup reads each second transaction passing the verification from the native chain, and executes the second transaction in the smart contract of the receiver. According to the method, consumption of on-chain computing and storage resources is effectively reduced, so that the throughput of the system is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of off-chain expansion of blockchains, and in particular to a cross-Rollup transaction method and device based on protogenesis links. Background Art

[0002] Rollup technology is widely regarded as an excellent off-chain expansion solution, but from the perspective of actual system development, a single Rollup system cannot meet all expansion needs. There are differences in the mechanism design of different Rollup systems, and these differences are intended to adapt to different business needs. Moreover, the upgrade of the Rollup system is currently mainly controlled by a few companies or communities, which may lead to the risk of centralized upgrades. In addition, a single Rollup system also has performance bottlenecks, and there is an upper limit to the performance optimization effect. In order to better meet actual needs, multiple forms of Rollup systems are necessary, and the diversity of the Rollup ecosystem is an inevitable trend.

[0003] As the business needs within Rollup continue to increase and become more complex, the need to exchange data and assets between different Rollup systems has become more urgent, which has promoted the research and development of Rollup interoperability technology. Rollup interoperability technology (also known as cross-Rollup technology) enables the interaction and transfer of data and assets between different Rollup systems, thereby promoting the circulation of value and the prosperity and development of the Rollup ecosystem. Therefore, research on cross-Rollup technology will help further promote the application and development of blockchain technology and provide blockchain ecosystem users with a more convenient transaction experience.

[0004] At present, technical solutions that can be used across Rollups have been clearly proposed, which can be generally divided into hash time locks and third-party service provider solutions. The hash time lock solution is only applicable to specific transaction scenarios, while the third-party service provider solution can be applied to general contract transactions.

[0005] Hash time lock is a multi-party transaction mechanism that enables two or more counterparties to conduct secure transactions without mutual trust by using cryptographic hash functions and time limits. Although hash time lock can be used for Rollup interoperability technology, it is only applicable to special asset exchange scenarios and cannot meet general contract transaction requirements. At the same time, its time-based restrictions may also cause inconvenience and uncertainty in transactions. This makes its use scenario very limited and not suitable for a wider application space.

[0006] In the third-party service provider solution, according to the different service objects of the service provider, it can be further divided into third-party proxy and third-party off-chain verification.

[19] The third-party proxy solution represented by Hop directly provides transaction services to users. The third-party service provider exists in both the sender Rollup and the receiver Rollup, and obtains the user's transaction agency rights. When the user initiates a transaction in the sender Rollup, the third-party service provider will execute the transaction in the receiver Rollup on behalf of the user after verifying that the transaction is successfully executed. For the receiver Rollup, it only needs to confirm that the third-party service provider has obtained the user's agency rights to execute the transaction reliably. Finally, the third-party node informs the user of the result of the proxy execution. The Hop solution does not require additional trust conditions between Rollups, but users need to trust the honesty and effectiveness of the third-party service provider to ensure that the third-party service provider has sent the proxy transaction and executed it successfully.

[0007] The third-party off-chain verification solution represented by OrbiterBridge, third-party service providers provide verification guarantee for transactions between Rollups. These service providers are specially connected to the sender's Rollup system, and can provide proof for transactions in the sender's Rollup, and jointly authenticate the authenticity and validity of the transaction. For the nodes in the receiving Rollup, they need to collectively trust that the service providers will provide proofs and that the proofs provided jointly are valid. This solution does not require users to trust the service providers, but only requires the receiving Rollup to trust that the third-party service providers are honest and reliable.

[0008] In summary, the current Rollup interoperability solutions are either not applicable to any cross-Rollup transactions, or adopt the strategy of introducing third-party service providers. The solution of introducing third-party service providers will bring additional trust risks. First, third-party service providers need to be trusted by all Rollup nodes or users in Rollup to play a role, and this trust assumption on service providers is relatively strong. If all service providers collude to commit fraud, losses will occur. Secondly, the introduction of third-party service providers leads to a single point of failure in cross-Rollup transactions, and the entire transaction process depends on the availability and security of the service provider. If the service provider is attacked or fails, the entire cross-Rollup transaction process will be seriously affected. Finally, third-party service providers will reduce the degree of decentralization of the network, and their control over the entire off-chain Rollup system network will be relatively high. This will affect the sustainability and stability of the entire Rollup expansion ecosystem, and a few service providers will control the lifeline of the system ecological upgrade. Summary of the invention

[0009] In response to the above problems, the present invention proposes a cross-Rollup transaction method and device based on protogenesis link, which completes the interoperability of Rollup without the participation of third-party service providers, effectively reduces the consumption of on-chain computing and storage resources, and thus improves the throughput of the system.

[0010] In order to achieve the above object, the present invention provides a cross-Rollup transaction method based on protogenesis link, comprising:

[0011] The user sends a single first transaction to the sender smart contract, and the sender smart contract executes the first transaction and generates a corresponding second transaction that needs to be executed in the receiver smart contract, wherein the first transaction is a transaction initiated by the user and executed in the sender Rollup, and the second transaction is a transaction to be executed in the receiver Rollup;

[0012] The sender Rollup waits for the aggregation of multiple first transactions to be executed in batches, and generates multiple corresponding second transactions to be stored on the protogenesis chain;

[0013] The sender Rollup verifies the validity of each of the second transactions on the protogenesis chain;

[0014] The receiving party Rollup reads each second transaction that has passed verification from the protogenesis link, and executes the second transaction in the receiving party smart contract.

[0015] Optionally, the sender Rollup uses a zero-knowledge proof strategy to verify the validity of each of the second transactions on the protogenesis chain, including:

[0016] Batch verify the multiple second transactions aggregated in the protogenesis link to generate multiple corresponding validity certificates;

[0017] Aggregating a plurality of the validity proofs to generate a valid zero-knowledge proof;

[0018] The zero-knowledge proof is used to verify the validity of each of the second transactions on the protogenesis link.

[0019] Optionally, the validity proof includes:

[0020] Verifying that the first transaction is successfully executed;

[0021] Verify that each of the second transactions stored on the protogenesis link is consistent with the second transaction generated by the sender transaction execution.

[0022] Optionally, a plaintext data input and a ciphertext data are input into a zero-knowledge proof function for verification, and if the verification is successful through the zero-knowledge proof function, a corresponding legal witness is generated;

[0023] The legal witness is combined with a prover parameter to generate the zero-knowledge proof.

[0024] Optionally, the plaintext data input includes a transaction receipt root list ReceiptRootList corresponding to the first transaction and a Merkle root Tx corresponding to the second transaction. receiver TreeRoot;

[0025] Among them, the set of transaction receipt tree roots involved in the batch of first transactions that have passed the validity verification on the protogenesis chain together forms a transaction receipt tree root list ReceiptRootList corresponding to the first transaction; all second transactions in the batch of proofs are combined into a Merkle tree root corresponding to the second transaction;

[0026] The ciphertext data input includes all first transaction lists Tx to be verified sender List, all second transaction lists uploaded to the protogenesis chain Tx receiver List, a list of transaction receipts corresponding to all first transactions ReceiptList, and a list of Merkle paths of transaction receipts corresponding to all first transactions ReceiptMerklePathList, where for each transaction receipt corresponding to the first transaction to be verified, there is an SPV Merkle path to prove that the receipt exists in the transaction receipt tree root list ReceiptRootList;

[0027] Optionally, the step of inputting a plaintext data input and a ciphertext data input into a zero-knowledge proof function for verification comprises:

[0028] Input the plaintext data and ciphertext data into a zero-knowledge proof function for verification, and judge the basic legality of the input one by one;

[0029] Retrieve the legitimacy of each transaction receipt in the transaction receipt list ReceiptList, and whether the corresponding first transaction is successfully executed;

[0030] Retrieve whether each transaction in the transaction receipt list ReceiptList exists in the transaction receipt tree root list ReceiptRootList;

[0031] Verify whether the cross-Rollup transaction tree generated by all transactions in the second transaction list is the Merkle tree root Tx in the plaintext data input receiver TreeRoot.

[0032] Optionally, the generation process of the zero-knowledge proof function includes:

[0033] Splitting the original zero-knowledge proof function into multiple parallelizable original parallel proof functions, where the parallelizable original parallel proof functions correspond to the first transaction to be verified of each proof;

[0034] Each original parallel proof function selects a parallel zero-knowledge proof algorithm and generates an auxiliary zero-knowledge proof;

[0035] All auxiliary zero-knowledge proofs and the verification serial functions in the original zero-knowledge proof function are combined into a final zero-knowledge proof function.

[0036] Optionally, storing the second transactions in batches on the protogenesis link in a manner of index table data compression includes:

[0037] An index table is deployed on the protogenesis link, and based on the index table, the high-frequency and long fields in the second transaction are compressed into short indexes, and the off-chain node restores the original transaction information before the index is replaced from the index table;

[0038] The index table includes an address table, a protocol table, and a data table, each of which is composed of a plurality of items, each of which includes a short index and a long field to be compressed;

[0039] The address table is used to compress the address information of the sender and the receiver by mapping a longer address length into a shorter short address index;

[0040] The data table is used in the contract transaction process to convert the longer string in the calldata field into a short index;

[0041] The protocol table is used to record the description of the data compression protocol.

[0042] Optionally, the index table data compression method includes address compression based on serial number, contract content compression based on long string, and parameter compression based on standardized template;

[0043] The address compression based on sequence number includes:

[0044] Sequentially number the addresses in the sender or receiver's Rollup, and construct a short index based on the number as the index of the complete address;

[0045] The contract content compression based on long strings includes:

[0046] Choose to compress the long string contract content through short hash;

[0047] The parameter compression based on the standardized template comprises:

[0048] For multiple parameters of calldata in the contract, find parameter clusters with similar characteristics and build a basic template;

[0049] Modify the numbered parameter forms and adjust the basic template;

[0050] A unique serial number is assigned to the adjusted basic template, and a mapping relationship between the template and the original parameters is implemented through a hash marking method.

[0051] Another aspect of the present invention provides a cross-Rollup transaction device based on protogenesis link, comprising:

[0052] A sending module, which is used for the user end to send a single first transaction to the sender smart contract, and the sender smart contract executes the first transaction and generates a corresponding second transaction that needs to be executed in the receiver smart contract, wherein the first transaction is a transaction initiated by the user end and executed in the sender Rollup, and the second transaction is a transaction to be executed in the receiver Rollup;

[0053] A batch storage module, used for the sender Rollup to wait for the aggregation of multiple first transactions to be executed in batches, and to generate multiple corresponding second transactions to be stored on the protogenesis chain;

[0054] A proof module, used by the sender Rollup to verify the validity of each of the second transactions on the protogenesis chain;

[0055] The receiving module is used for the receiving party Rollup to read each second transaction that has passed the verification from the protogenesis link, and execute the second transaction in the receiving party smart contract.

[0056] It can be seen from the above scheme that the advantages of the present invention are:

[0057] The cross-Rollup transaction method based on protogenesis provided by the present invention reduces the average computation and storage overhead of a single transaction by aggregating transactions in batches for centralized processing, thereby increasing the throughput of the system. Specifically: a single first transaction is sent to the sender's smart contract through the user end, and the sender's smart contract executes the first transaction and generates a corresponding second transaction that needs to be executed in the receiver's smart contract. Then, the sender's Rollup waits for the batch execution of multiple aggregated first transactions, and generates multiple corresponding second transactions stored in the protogenesis chain; the sender's Rollup verifies the validity of each of the second transactions on the protogenesis chain; finally, the receiver's Rollup reads each second transaction that has passed the verification from the protogenesis chain, and executes the second transaction in the receiver's smart contract. In this method, a batch processing method is adopted to batch generate the validity proofs of transactions in the sender's Rollup. At the same time, the simplicity of zero-knowledge proof is utilized to aggregate multiple transaction proofs into one zero-knowledge proof, thereby significantly reducing the on-chain computational overhead of transaction validity verification. In addition, the present invention also provides a new cross-Rollup transaction batch processing data structure, which stores transaction batches on the native chain, takes advantage of the high access frequency of a few data fields, compresses high-frequency long fields into short indexes through index tables, and reduces the average on-chain storage overhead of cross-Rollup transactions while ensuring data integrity. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 A schematic diagram of a process of a cross-Rollup transaction method based on protogenesis linking provided in an embodiment of the present invention is shown;

[0059] Figure 2 shows the data structure of the index table;

[0060] Figure 3 The overall flow chart of the zero-knowledge proof algorithm is shown;

[0061] Figure 4 A schematic diagram of parallelization of zero-knowledge proof is shown;

[0062] Figure 5 The following is an architecture diagram of the cross-Rollup transaction device based on protogenesis link;

[0063] in,

[0064] 200-Cross-Rollup transaction device based on protogenesis link;

[0065] 201-sending module;

[0066] 202-Batch storage module;

[0067] 203-Proof module;

[0068] 204-receiving module. DETAILED DESCRIPTION

[0069] In order to make the above features and effects of the present invention more clearly understood, embodiments are given below and described in detail with reference to the accompanying drawings.

[0070] As mentioned above, the native blockchain (hereinafter referred to as: protogenesis link) is the trust foundation of the Rollup system. The transaction proof provided by the protogenesis link can be directly trusted by the Rollup system, which means that the solution using the protogenesis link can avoid introducing additional trust assumptions, thereby fundamentally avoiding the trust assumption risks brought by third-party service providers. Due to the low transaction throughput of the protogenesis link and limited computing and storage resources, directly using off-chain proofs and storage strategies will make the average on-chain overhead of a single transaction too large, which will lead to low transaction throughput of Rollup interoperability.

[0071] In order to complete the interoperability between Rollups without the assumption of trust, the present invention proposes a cross-Rollup solution based on the protogenesis link, which completes the interoperability of Rollups without the participation of third-party service providers, reduces the consumption of on-chain computing and storage resources, and improves the efficiency of cross-Rollup transaction processing. In addition, the present invention adopts a batch processing method to batch generate the validity proofs of transactions in the sender's Rollup. At the same time, by utilizing the simplicity of zero-knowledge proofs, multiple transaction proofs are aggregated into one zero-knowledge proof, thereby significantly reducing the on-chain computing overhead of transaction validity verification; further, the present invention proposes a new cross-Rollup transaction batch processing data structure, which utilizes the high access frequency of a few data fields, and compresses high-frequency long fields into short indexes through index tables, etc., on the basis of ensuring data integrity, reduces the average on-chain storage overhead of cross-Rollup transactions. The scheme of the present invention will be described in detail below.

[0072] like Figure 1 As shown in Figure 1 The overall process diagram of the cross-Rollup transaction method based on protogenesis link provided by an embodiment of the present invention is shown as follows:

[0073] A cross-Rollup transaction method based on protogenesis link, comprising:

[0074] S1. The user sends a single first transaction Tx sender To the sender smart contract sender , sender smart contract Contract sender Execute the first transaction Tx sender , generate the corresponding smart contract required on the receiving side receiverThe second transaction executed within Tx receiver , where the first transaction is a transaction initiated by the user and executed in the sender's Rollup, and the second transaction is a transaction to be executed in the receiver's Rollup.

[0075] S2. Sender Rollup sender ) Wait for the aggregation of multiple first transactions to be executed in batches, and generate multiple corresponding second transactions to be stored on the protogenesis link.

[0076] In order to reduce the on-chain computing resource overhead of verifying transactions in the sender's Rollup, in this embodiment, the sender's Rollup (Rollup sender ) Wait for aggregating multiple first transactions for batch execution, and store the generated multiple corresponding second transactions on the protogenesis link. By aggregating multiple transactions for batch centralized processing, the average calculation and storage overhead of a single transaction is reduced, thereby increasing the throughput of the system.

[0077] In addition, in order to reduce the on-chain storage overhead of cross-Rollup transactions, this embodiment proposes a new cross-Rollup transaction batch processing data structure, which utilizes the high access frequency of a few data fields, and uses short indexes to replace the original fields in the form of index tables deployed on the chain, thereby reducing the average on-chain storage overhead of cross-Rollup transactions while ensuring data integrity. Specifically, in the process of storing the second transaction in batches on the native chain in a manner of index table data compression, the high-frequency long fields in the second transaction are compressed into short indexes based on the index table by deploying the index table on the native chain, and the off-chain nodes restore the original transaction information before the index replacement from the index table. Therefore, in the actual on-chain transaction storage process, only short indexes are actually stored in the transaction, and the mapping relationship between long fields and short indexes is updated in the on-chain index table. The subsequent off-chain nodes restore the original transaction information before the index replacement from the index table. The data in the index table only needs to be updated once to be used permanently. For example, the index relationship of a contract address only needs to update the corresponding relationship in the index table when it is first deployed, and the index table can be used directly for any number of uses thereafter, thereby saving on-chain storage costs.

[0078] In addition, for index table structures such as Figure 2 As shown in , it includes an address table, a protocol table, a data table, etc., wherein the address table, the protocol table, and the data table are composed of multiple items, each of which includes a short index key and a long field value to be compressed.

[0079] Specifically, the address table is used to compress the address information of the sender and receiver, and effectively compresses the address information by mapping longer address lengths to shorter short address indexes. The data table is used in the contract transaction process to convert longer strings in the calldata field into short indexes.

[0080] In addition, it is worth noting that in a Rollup, multiple contracts may be deployed. Since the calling methods between different contracts are different, multiple data tables are required to distinguish them. Generally, calldata can be regarded as a call to the contract function interface, and the incoming data is the parameters required for the function interface call. However, not all parameters need to be compressed based on the index table. For example, if the parameter is a Boolean value, no compression is required. Therefore, a data compression protocol is required to clearly indicate which parameters use index table-based data compression during the transaction call, which parameters are not used, and which index data table is used. The protocol table is responsible for recording the description of these data compression protocols. In the protocol table, the value value is used to store the protocol description, and the key value is a simple serial number. Through such a design, different types of index tables can be effectively organized and managed, thereby achieving efficient compression of information such as addresses, data, and protocols.

[0081] Different from traditional data compression protocols such as gzip, the present invention uses a batch data storage method based on an index table to map long fields into short indexes. Data compression is not achieved through the repeatability of the long field itself, but by using the field to reduce overhead under the premise that there is a need for multiple uses in the future. This makes the solution highly flexible and widely applicable. For compressible fields, as long as it can be confirmed that the same content of the field may be called repeatedly in the future, the index table can be compressed. It only needs to ensure that there is no conflict between the mapped short indexes.

[0082] In the specific implementation, the compression methods of address compression based on serial number, contract content compression based on long string, and parameter compression based on standardized template can be collected to store batch data in the index table. Specifically:

[0083] Among them, the address compression method based on serial numbers is: the addresses in the sender or receiver's Rollup are numbered sequentially, and a short index is constructed based on the number as the index of the complete address. Through this serial number-based address compression method, the storage and transmission costs of the address can be significantly reduced while maintaining data integrity. The advantage of this method is that the addresses that can be traded in the Rollup need to be stored in the Rollup node in advance to enter the address set, and only the addresses in the address set will be recognized as valid transactions. It is only necessary to number them in the order in which they enter the address set, use the serial number as the compressed address, and store it in the index table as a short index, so that the address mapping relationship will inevitably not cause conflicts.

[0084] Among them, based on the compression of contract content of long strings, it compresses the contract content of long strings in the calldata parameters of smart contracts through short hashes to improve storage and transmission efficiency. Taking non-fungible tokens (NFTs) as an example, the smart contracts in the casting process usually contain some URL information about NFT storage images. These URLs have high similarity and are usually stored under a base site. Therefore, the common parts of these URLs can be extracted as the base site to achieve compression of the original strings. In this way, the originally lengthy strings in the contract can be effectively compressed, reducing the amount of data in the storage and transmission process and improving overall efficiency.

[0085] Among them, parameter compression based on standardized templates is applied to the case where the parameters of multiple transactions are roughly similar, and a basic template is used to represent these similar parameters, so as to achieve the goal of compressing data. In the implementation process of this method, it is necessary to number the basic template and use the serial number hash annotation to realize the mapping relationship between the template and the original parameters. Specifically, for multiple parameters of calldata in the contract, find parameter clusters with similar characteristics and build a basic template. The design of the basic template should fully consider the distribution characteristics of the parameters and the correlation between the parameters, so as to achieve an accurate description of the data characteristics; then, modify the numbered parameter form and adjust the basic template; finally, give the adjusted basic template a unique serial number, and realize the mapping relationship between the template and the original parameters through the hash annotation method. The serial number hash annotation can specifically use a hash function or other hash algorithm to map the original parameters to the corresponding template serial number. When the original parameters need to be restored, it is only necessary to find the corresponding basic template in the index table according to the serial number, and make reverse adjustments according to the parameter differences to achieve data decompression.

[0086] S3, the sender Rollup sender ) Verify the validity of each second transaction on the protogenesis chain.

[0087] In order to further reduce the on-chain computing resource overhead of verifying transactions in the sender's Rollup, this embodiment batch verifies the validity of the second transaction stored in the protogenesis link. First, the sender's Rollup batch verifies multiple second transactions aggregated in the protogenesis link and generates multiple corresponding validity proofs; for the validity proof, it mainly includes two goals: verifying the successful execution of the first transaction; and verifying that each second transaction stored in the protogenesis link is consistent with the second transaction generated by the sender's transaction execution. In addition, in this embodiment, it is necessary not only to complete the target verification of the transaction validity, but also to optimize the resource utilization efficiency in the blockchain transaction verification process during the verification process. In this regard, this embodiment combines the zero-knowledge proof strategy in the batch processing process and utilizes the simplicity of the zero-knowledge proof. After the sender's Rollup batch verifies multiple second transactions aggregated in the protogenesis link and generates multiple corresponding validity proofs, the multiple validity proofs are aggregated to generate a valid zero-knowledge proof, and the zero-knowledge proof is used to verify the validity of each second transaction on the protogenesis link as a whole. This method aggregates multiple validity proofs into one zero-knowledge proof to realize batch verification of multiple second transactions, thereby reducing the occupation of on-chain resources and the time cost of transaction verification, and improving the transaction processing efficiency of the entire system.

[0088] In the specific implementation, the zero-knowledge proof scheme can generate a valid zero-knowledge proof to provide to the verifier to prove the validity of its calculation. It usually requires two parts: plaintext data input and ciphertext data input, and finally generates a valid zero-knowledge proof. For the specific process, see Figure 3 , where the plaintext data input is information that is public to both the sender and the receiver, and the ciphertext data input is secret data calculated by the sender input, but is not public to the receiver. A plaintext data input and a ciphertext data input are input into a zero-knowledge proof function for verification. If the zero-knowledge proof function successfully verifies, it can be proved that the batch of inputs can pass the proof function check, and a corresponding legal witness is generated; in practice, the zero-knowledge proof function will be converted into a zero-knowledge proof generation circuit R1CS, and the result of successful circuit verification will generate a unique corresponding legal witness (witness). If the circuit verification fails, no valid result will be generated. Then, the legal witness is combined with a prover parameter to generate a valid zero-knowledge proof. Specifically:

[0089] For plaintext data input, its data structure is shown in Table 1, including a transaction receipt root list ReceiptRootList corresponding to the first transaction, and a Merkle root Tx corresponding to the second transaction receiverTreeRoot; where all the transaction receipt tree roots involved in the batch of first transactions that have passed the validity verification on the protogenesis chain are collectively formed into a transaction receipt tree root list ReceiptRootList corresponding to the first transaction; all the second transactions in the batch of proofs are combined into a Merkle tree, whose root is the Merkle tree root Tx corresponding to the second transaction receiver TreeRoot.

[0090] Table 1 Zero-knowledge proof plaintext data input

[0091] Plain text input field Specific meaning ReceiptRootList Transaction receipt tree root list corresponding to the first transaction <![CDATA[Tx receiver TreeRoot]]> All second transactions in the batch proof are combined into a Merkle tree

[0092] For ciphertext data input, its data structure is shown in Table 2, which contains all the first transaction lists Tx to be verified. sender List, all second transaction lists uploaded to the protogenesis chain Tx receiver List, a list of transaction receipts corresponding to all first transactions ReceiptList, and a list of Merkle path proofs of transaction receipts corresponding to all first transactions ReceiptMerklePathList, where, for each transaction receipt corresponding to the first transaction to be verified, there will be an SPV proof Merkle path to prove that the receipt exists in the transaction receipt tree root list ReceiptRootList.

[0093] Table 2 Zero-knowledge proof ciphertext data input

[0094] Cipher text input field Specific meaning <![CDATA[Tx sender List]]> List of all sender transactions <![CDATA[Tx receiver List]]> List of all receiver transactions ReceiptList List of transaction receipts for the original transaction ReceiptMerklePathList List of Merkle path proofs of the original transaction receipts

[0095] In addition, for the zero-knowledge proof function, since the proof function of the zero-knowledge proof implemented in the cross-Rollup transaction verification has a highly parallelizable part. The traditional zero-knowledge proof generation process is usually executed in a single thread, and the parallelized zero-knowledge proof can use multi-threaded parallelization to generate the proof process and reduce the time of proof generation. Therefore, this embodiment chooses to parallelize the zero-knowledge proof. By parallelizing the proof, the generation speed of a single zero-knowledge proof can be increased, so that the system can handle larger-scale proof tasks. This can increase the transaction volume of a single zero-knowledge proof, further reduce the average on-chain computing cost of a single transaction, and improve the performance and efficiency of the system. The core idea of ​​the parallel proof strategy is to select a zero-knowledge proof method as a parallel proof strategy, and select a zero-knowledge proof algorithm to generate the final zero-knowledge proof proof, and prove the validity of the overall proof by proving the validity of the evidence of the zero-knowledge proof under the parallelization strategy.

[0096] Specifically, the parallelized zero-knowledge proof function structure is as follows Figure 4As shown in , the generation process of the zero-knowledge proof function specifically includes: first, splitting the original zero-knowledge proof function into multiple parallelizable original parallel proof functions, and the parallelizable original parallel proof function corresponds to the first transaction to be verified of each proof. Since there is no dependency between the verifications of different transactions, it is feasible to generate zero-knowledge proofs independently. Then, each original parallel proof function selects a parallel zero-knowledge proof algorithm to generate an auxiliary zero-knowledge proof, that is, each original parallel proof function independently uses the parallel zero-knowledge proof algorithm to obtain multiple auxiliary zero-knowledge proof modules; finally, all auxiliary zero-knowledge proofs and the verification serial functions in the original zero-knowledge proof function are merged into the final zero-knowledge proof function, that is, the overall zero-knowledge proof.

[0097] Overall, the goal of zero-knowledge proof is to verify that all second transactions stored on the protogenesis chain can pass the validity check of the proof function. Verifying the auxiliary zero-knowledge proof of the parallelized part is actually equivalent to using the parallelized zero-knowledge proof algorithm to prove the validity of a single transaction. Therefore, as long as the verification of the zero-knowledge proof of each transaction is valid, it is equivalent to the validity of the original zero-knowledge proof function of the single transaction. The final zero-knowledge proof function consists of the verification of all parallelized zero-knowledge proof evidences and the original serial part. Therefore, if the evidence of zero-knowledge proof can be generated in the end, it proves that the original zero-knowledge proof function of each transaction is valid, and then the validity of the overall proof function can be deduced.

[0098] Therefore, in this embodiment, the sender Rollup sender ) In the process of verifying the validity of each second transaction on the protogenesis chain, after completing the above construction of the plaintext data input and the ciphertext data input, and the final zero-knowledge proof function, the above-constructed plaintext data input and the ciphertext data input are input into the final zero-knowledge proof function for verification using the final zero-knowledge proof function, that is: the basic legality of the input is judged one by one; at the same time, the legality of each transaction receipt in the transaction receipt list ReceiptList corresponding to the first transaction is retrieved, and whether the corresponding first transaction is successfully executed; and whether each transaction in the transaction receipt list ReceiptList corresponding to the first transaction exists in the transaction receipt tree root list ReceiptRootList corresponding to the first transaction; finally, verify whether the cross-Rollup transaction tree generated by all transactions in the second transaction list is the Merkle tree root Tx in the plaintext data input rreceiver TreeRoot.

[0099] Compared with traditional transaction verification, in the traditional transaction verification process, each transaction needs to generate and verify the SPV proof separately, which will cause the on-chain computing cost to increase linearly with the transaction volume. In contrast, this embodiment is based on the batch zero-knowledge proof strategy, and the sender Rollup batch verifies multiple second transactions aggregated in the protogenesis chain, generates multiple corresponding validity proofs, and aggregates multiple validity proofs to generate a valid zero-knowledge proof, and uses the zero-knowledge proof to verify the validity of each second transaction on the protogenesis chain as a whole. This method aggregates multiple validity proofs into one zero-knowledge proof to realize batch verification of multiple second transactions. The more transactions are incorporated, the less the total overhead of the zero-knowledge proof will increase significantly, thereby greatly reducing the average computing cost of a single transaction. In addition, in the batch zero-knowledge proof strategy, since the proof process of the Merkle tree of different transactions is independent of each other, the parallelization of zero-knowledge proof can be realized through the optimization algorithm, the efficiency of proof generation is improved, and the problem of too long zero-knowledge proof generation process is better alleviated.

[0100] S4. Receiver Rollup receiver ) Read each verified second transaction from the protogenesis link and send it to the recipient smart contract (Contract receiver ) to execute the second transaction.

[0101] In summary, the cross-Rollup transaction method based on the protogenesis link provided by the present invention reduces the average computation and storage overhead of a single transaction by aggregating transactions in batches for centralized processing, thereby increasing the throughput of the system. Specifically: a single first transaction is sent from the user end to the sender's smart contract, and the sender's smart contract executes the first transaction to generate a corresponding second transaction that needs to be executed in the receiver's smart contract. Then, the sender's Rollup waits for the aggregation of multiple first transactions to be executed in batches, and generates multiple corresponding second transactions stored on the protogenesis link; the sender's Rollup verifies the validity of each second transaction on the protogenesis link; finally, the receiver's Rollup reads each second transaction that has passed the verification from the protogenesis link, and executes the second transaction in the receiver's smart contract. In this method, a batch processing method is adopted to batch generate the validity proofs of transactions in the sender's Rollup. At the same time, the simplicity of zero-knowledge proof is utilized to aggregate multiple transaction proofs into one zero-knowledge proof, thereby significantly reducing the on-chain computational overhead of transaction validity verification.

[0102] In addition, the present invention also provides a new cross-Rollup transaction batch processing data structure, which stores transaction batches on the native chain, takes advantage of the high access frequency of a few data fields, compresses high-frequency long fields into short indexes through index tables, and reduces the average on-chain storage overhead of cross-Rollup transactions while ensuring data integrity.

[0103] In addition, the above embodiments of the present invention can be applied to a terminal device with a cross-Rollup transaction method function based on protogenesis link, and the terminal device can include a personal terminal and a host terminal, etc., which is not limited by the embodiments of the present invention. The terminal can support operating systems such as Windows, Linux, and Mac.

[0104] A cross-Rollup transaction device 200 based on protogenesis link, which is applied to a cross-Rollup transaction method based on protogenesis link, can be applied to a personal terminal and a host terminal device, which can be implemented by Figure 1 The cross-Rollup transaction method based on protogenesis link shown in the figure, the cross-Rollup transaction device based on protogenesis link provided in the embodiment of the present application can implement each process implemented by the cross-Rollup transaction method based on protogenesis link.

[0105] Figure 5 The following is an architecture diagram of the protogenesis link-based cross-Rollup transaction device 200.

[0106] A cross-Rollup transaction device based on protogenesis link at least comprises a sending module 201, a batch storage module 202, a certification module 203, and a receiving module 204, wherein:

[0107] The sending module 201 is used for the user end to send a single first transaction to the sender smart contract. The sender smart contract executes the first transaction and generates a corresponding second transaction that needs to be executed in the receiver smart contract, wherein the first transaction is a transaction initiated by the user end and executed in the sender Rollup, and the second transaction is a transaction to be executed in the receiver Rollup;

[0108] Batch storage module 202, used for the sender Rollup to wait for the aggregation of multiple first transactions to be executed in batches, and to generate multiple corresponding second transactions to be stored on the protogenesis chain;

[0109] Proof module 203, used by the sender Rollup to verify the validity of each second transaction on the protogenesis chain;

[0110] The receiving module 204 is used for the receiving Rollup to read each second transaction that has passed the verification from the protogenesis link, and execute the second transaction in the receiving smart contract.

[0111] In addition, it should be understood that in the cross-Rollup transaction device 200 based on the protogenesis link according to the embodiment of the present application, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the cross-Rollup transaction device 200 based on the protogenesis link can be divided into functional modules different from the modules illustrated above to complete all or part of the functions described above.

[0112] An embodiment of the present application also provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the above-mentioned cross-Rollup transaction method based on protogenesis link are implemented, and the same technical effect can be achieved.

[0113] To avoid repetition, other technical effects of the readable storage medium according to the embodiments of the present application are not described here.

[0114] It should be noted that, in this article, the term "comprises", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or device containing a series of elements not only contains those elements, but also contains other elements that are not explicitly listed, or also contains elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprising a ..." do not exclude the presence of other identical elements in the process, method, article or device containing the element. In addition, it should be pointed out that the scope of the method and device in the embodiment of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in the opposite order according to the functions involved, for example, the described method may be performed in an order different from that described, and various steps may also be applied, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.

[0115] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

Claims

1. A cross-Rollup transaction method based on protogenesis link, characterized in that: Include: The user sends a single first transaction to the sender smart contract, and the sender smart contract executes the first transaction and generates a corresponding second transaction that needs to be executed in the receiver smart contract, wherein the first transaction is a transaction initiated by the user and executed in the sender Rollup, and the second transaction is a transaction to be executed in the receiver Rollup; The sender Rollup waits for the aggregation of multiple first transactions to be executed in batches, and generates multiple corresponding second transactions to be stored on the protogenesis chain; The sender Rollup verifies the validity of each of the second transactions on the protogenesis chain; The receiving party Rollup reads each second transaction that has passed verification from the protogenesis link, and executes the second transaction in the receiving party smart contract.

2. The method according to claim 1, characterized in that The sender Rollup verifies the validity of each of the second transactions on the protogenesis chain using a zero-knowledge proof strategy, including: Batch verify the multiple second transactions aggregated in the protogenesis link to generate multiple corresponding validity certificates; Aggregating a plurality of the validity proofs to generate a valid zero-knowledge proof; The zero-knowledge proof is used to verify the validity of each of the second transactions on the protogenesis link.

3. The method according to claim 2, characterized in that The validity proof includes: Verifying that the first transaction is successfully executed; Verify that each of the second transactions stored on the protogenesis link is consistent with the second transaction generated by the sender transaction execution.

4. The method according to claim 2, characterized in that: Input a plaintext data and a ciphertext data into a zero-knowledge proof function for verification. If the zero-knowledge proof function succeeds in verification, a corresponding legal witness is generated; The legal witness is combined with a prover parameter to generate the zero-knowledge proof 。 5. The method according to claim 4, characterized in that The plaintext data input includes a transaction receipt root list ReceiptRootList corresponding to a first transaction and a Merkle root Tx corresponding to a second transaction receiver TreeRoot; Among them, the set of transaction receipt tree roots involved in the batch of first transactions that have passed the validity verification on the protogenesis chain together forms a transaction receipt tree root list ReceiptRootList corresponding to the first transaction; all second transactions in the batch of proofs are combined into a Merkle tree root corresponding to the second transaction; The ciphertext data input includes all first transaction lists Tx to be verified sender List, a list of all second transactions uploaded to the protogenesis chain Tx receiver List, a list of transaction receipts corresponding to all first transactions ReceiptList, and a Merkle path proof list of transaction receipts corresponding to all first transactions ReceiptMerklePathList, where, for each transaction receipt corresponding to the first transaction to be verified, there will be an SPV proof Merkle path to prove that the receipt exists in the transaction receipt tree root list ReceiptRootList.

6. The method according to claim 5, characterized in that The step of inputting a plaintext data input and a ciphertext data input into a zero-knowledge proof function for verification comprises: Input the plaintext data and ciphertext data into a zero-knowledge proof function for verification, and judge the basic legality of the input one by one; Retrieve the legitimacy of each transaction receipt in the transaction receipt list ReceiptList, and whether the corresponding first transaction is successfully executed; Retrieve whether each transaction in the transaction receipt list ReceiptList exists in the transaction receipt tree root list ReceiptRootList; Verify whether the cross-Rollup transaction tree generated by all transactions in the second transaction list is the Merkle tree root Tx in the plaintext data input receiver TreeRoot.

7. The method according to any one of claims 4 to 6, characterized in that: The generation process of the zero-knowledge proof function includes: Splitting the original zero-knowledge proof function into multiple parallelizable original parallel proof functions, where the parallelizable original parallel proof functions correspond to the first transaction to be verified of each proof; Each original parallel proof function selects a parallel zero-knowledge proof algorithm and generates an auxiliary zero-knowledge proof; All auxiliary zero-knowledge proofs and the verification serial functions in the original zero-knowledge proof function are combined into a final zero-knowledge proof function.

8. The method according to claim 1, characterized in that The method of storing the second transaction in batches on the protogenesis link based on the index table data compression method includes: An index table is deployed on the protogenesis link, and based on the index table, the high-frequency and long fields in the second transaction are compressed into short indexes, and the off-chain node restores the original transaction information before the index is replaced from the index table; The index table includes an address table, a protocol table, and a data table, each of which is composed of a plurality of items, each of which includes a short index and a long field to be compressed; The address table is used to compress the address information of the sender and the receiver by mapping a longer address length into a shorter short address index; The data table is used in the contract transaction process to convert the longer string in the calldata field into a short index; The protocol table is used to record the description of the data compression protocol.

9. The method according to claim 8, characterized in that The index table data compression methods include address compression based on serial numbers, contract content compression based on long strings, and parameter compression based on standardized templates; The address compression based on sequence number includes: Sequentially number the addresses in the sender or receiver's Rollup, and construct a short index based on the number as the index of the complete address; The contract content compression based on long strings includes: Choose to compress the long string contract content through short hash; The parameter compression based on the standardized template comprises: For multiple parameters of calldata in the contract, find parameter clusters with similar characteristics and build a basic template; Modify the numbered parameter forms and adjust the basic template; A unique serial number is assigned to the adjusted basic template, and a mapping relationship between the template and the original parameters is implemented through a hash marking method.

10. A cross-Rollup transaction device based on protogenesis link, characterized in that: Include: A sending module, which is used for the user end to send a single first transaction to the sender smart contract, and the sender smart contract executes the first transaction and generates a corresponding second transaction that needs to be executed in the receiver smart contract, wherein the first transaction is a transaction initiated by the user end and executed in the sender Rollup, and the second transaction is a transaction to be executed in the receiver Rollup; A batch storage module, used for the sender Rollup to wait for the aggregation of multiple first transactions to be executed in batches, and to generate multiple corresponding second transactions to be stored on the protogenesis chain; A proof module, used by the sender Rollup to verify the validity of each of the second transactions on the protogenesis chain; The receiving module is used for the receiving party Rollup to read each second transaction that has passed the verification from the protogenesis link, and execute the second transaction in the receiving party smart contract.

Images