Decentralized storage and hybrid rollup scaling system and method

Abstract

The application relates to the technical field of blockchains, in particular to a decentralized storage and hybrid Rollup expansion system and method. The system comprises a DAC storage node that receives and stores transaction data; an orderer that obtains the transaction data and distributes the transaction data to a ZK aggregator or an OP aggregator; the ZK aggregator performs batch processing on the distributed transaction data to generate zero-knowledge processing results; the OP aggregator performs batch processing on the distributed transaction data to generate optimistic processing results; the DAC storage node is used to update a state tree based on the zero-knowledge processing results and / or the optimistic processing results to obtain state update results; the orderer is further used to check the state update results, and if the state conversion is incorrect, the state conversion is rejected and a suspicious label is added; the state update results are aggregated based on a KZG polynomial commitment algorithm to generate an incremental state root commitment and an aggregation proof; and the incremental state root commitment and the aggregation proof are submitted to a main chain.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a decentralized storage and hybrid Rollup scaling system and method. Background Technology

[0002] With the widespread adoption of Layer-2 blockchain scaling solutions, data availability (DA) has become a key bottleneck restricting system scalability and cost control. Existing mainstream Rollup solutions suffer from several problems in practical applications: Firstly, traditional solutions typically rely on static committees or centralized sorters and are entirely dependent on on-chain storage, resulting in insufficient decentralization and a risk of single points of failure. Secondly, on-chain storage costs increase exponentially with transaction volume; to ensure data availability, a large amount of raw transaction data needs to be uploaded, significantly increasing gas fees and storage burden.

[0003] Furthermore, existing solutions also have limitations in state verification and transaction data processing. Traditional Rollup systems mostly assume that transaction data can be fully synchronized to off-chain nodes and rely on on-chain state trees for state updates. However, when the amount of off-chain data is large and node participation changes dynamically, the system struggles to balance efficiency and cost control while ensuring the correctness of state updates. At the same time, for data containing EVM execution bytecode or complex transaction logic, existing routing and aggregation mechanisms are inefficient in allocating resources between zero-knowledge verification and optimistic processing, which may lead to processing delays or security vulnerabilities.

[0004] Therefore, existing technologies struggle to balance data availability, scalability, and system security, which limits the widespread application of blockchain layer-2 scaling solutions in high-frequency trading and high-throughput scenarios. Summary of the Invention

[0005] (a) Technical problems to be solved In view of the above-mentioned shortcomings and deficiencies of the prior art, this application provides a decentralized storage and hybrid Rollup scaling system and method, which solves the technical problems of high on-chain storage costs, difficulty in ensuring data availability, single point of failure in centralized or static sorting mechanisms, low efficiency of state update verification, and inflexible processing of off-chain transaction data in existing Rollup schemes.

[0006] (II) Technical Solution To achieve the above objectives, the main technical solutions adopted in this application include: In a first aspect, embodiments of this application provide a decentralized storage and hybrid Rollup scaling system, including: DAC storage nodes are used to receive and store transaction data submitted by users; A sorter is used to obtain transaction data from the DAC storage node and allocate the transaction data to the ZK aggregator or OP aggregator according to preset routing rules. The ZK aggregator, which is communicatively connected to the sorter, is used to batch process the allocated transaction data and generate zero-knowledge processing results. The OP aggregator, which is communicatively connected to the sorter, is used to batch process the allocated transaction data and generate optimistic processing results. The DAC storage node is further configured to: update the state tree on the main chain based on the zero-knowledge processing result and / or the optimistic processing result, obtain the state update result, and send the state update result to the sorter; The sorter is also used to: check the state update result; if the state transition is found to be incorrect, reject the state transition and mark it as suspicious. Based on the KZG multinomial commitment algorithm, the state update results are aggregated to generate incremental state root commitments and aggregated proofs. Submit the incremental state root commitment and the aggregated proof to the main chain.

[0007] Preferably, in some embodiments of this application, the DAC storage node is elected through a dynamically rotating data availability committee mechanism, specifically including: electing DAC storage nodes from candidate nodes based on the WRR algorithm; the elected DAC storage node registers its public key in the main chain and provides a data availability query interface; wherein, the candidate node is a full node that can synchronize complete off-chain transaction data and whose account root node hash value is consistent with the main chain account Merkle root.

[0008] Preferably, in some embodiments of this application, the full node is a network node whose storage capacity meets preset requirements.

[0009] Preferably, in some embodiments of this application, there is at least one honest user in the system, who stores complete off-chain data in the form of SMT, the off-chain data including all historical transaction records and account status.

[0010] Preferably, in some embodiments of this application, the state tree on the main chain adopts a sparse Merkle tree (SMT) structure, including: an account state tree, whose leaf nodes store basic account information and embed the root node hash of the account transaction index tree; an account transaction index tree, whose leaf nodes store the transaction hash value of the corresponding account; and a global transaction storage tree, whose leaf nodes store complete transaction records and state change summaries after transaction execution.

[0011] Preferably, in some embodiments of this application, the account state tree is constructed based on a 160-bit address encoding standard, and the tree depth is fixed at 160 levels; the leaf nodes of the account state tree store basic account information, sorter cluster member status, DAC node identifier, and the root node hash of the account transaction index tree; the leaf nodes of the account transaction index tree store the Keccak256 hash value of the corresponding transaction; the leaf nodes of the global transaction storage tree store transaction metadata, numerical parameters, transaction execution final state identifier, transaction body hash fingerprint, and user signature.

[0012] Preferably, in some embodiments of this application, the process of generating incremental state root commitments and aggregate proofs by the KZG polynomial commitment algorithm includes: calculating incremental state root commitments based on the original commitments and updated commitments during batch state changes; generating corresponding quotient polynomials according to the node position weights of the sparse Merkle tree; and aggregating the quotient polynomials to obtain aggregate proofs.

[0013] Preferably, in some embodiments of this application, the sorter allocates transaction data to a ZK aggregator or an OP aggregator according to a preset routing rule. The routing rule is as follows: obtain the data field of the transaction data; if the data field does not contain bytecode executed on the EVM, then the transaction data is allocated to the ZK aggregator; if the data field of the transaction data contains bytecode executed on the EVM, then the transaction is allocated to the OP aggregator.

[0014] Preferably, in some embodiments of this application, the process by which the sorter verifies the state update result includes: calculating the corresponding incremental state root commitment based on the state update result provided by the DAC storage node, comparing the calculated incremental state root commitment with the state root in the state update result, and determining that the state transition is incorrect when the calculated incremental state root commitment is inconsistent with the state root in the state update result, rejecting the state transition, and marking the state transition as suspicious.

[0015] Secondly, embodiments of this application also provide a decentralized storage and hybrid Rollup scaling method, which is executed by the aforementioned decentralized storage and hybrid Rollup scaling system.

[0016] (III) Beneficial Effects The decentralized storage and hybrid Rollup scaling system and method provided in this application achieve efficient storage and processing of off-chain transaction data by introducing dynamically rotated DAC storage nodes and a routing rule-based ZK / OP aggregator allocation mechanism. By performing incremental state root commitment verification on the state update results in the sorter, transactions with incorrect state transitions can be detected in a timely manner and marked as suspicious, preventing erroneous states from being submitted to the main chain. The KZG multinomial commitment algorithm is used to aggregate the state update results to generate incremental state root commitments and aggregated proofs, improving the efficiency and reliability of state verification. The overall solution reduces on-chain storage costs, enhances the decentralization of the system, and ensures the availability and integrity of transaction data, thereby improving the security, reliability, and operational stability of the system while maintaining scaling performance. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the structure of a decentralized storage and hybrid Rollup expansion system according to an embodiment of this application; Figure 2 This is a schematic diagram illustrating the topological relationship between the account status tree, the account transaction index tree, and the global transaction storage tree according to one embodiment of this application. Detailed Implementation

[0018] To better explain and facilitate understanding of this application, the following detailed description of the application is provided in conjunction with the accompanying drawings and specific embodiments.

[0019] In existing technologies, there are three main limitations in data storage, state verification, and transaction processing for Layer-2 Rollup scaling solutions: The first type is a scaling solution based on static on-chain storage and a centralized sorting mechanism. This type of solution relies on fixed storage nodes or a centralized sorter to upload all transaction data to the main chain and update it through an on-chain state tree. This method is highly dependent on data availability; if the participation of off-chain nodes is uneven or they malfunction, state updates may be delayed or incorrect. At the same time, on-chain storage costs increase exponentially with transaction volume, and when processing high-frequency transactions, gas fees and storage burdens increase significantly.

[0020] The second category is based on traditional Rollup aggregation and state verification schemes. These schemes typically employ a unified zero-knowledge or optimistic verification mechanism to batch process all transaction data. While they can guarantee a certain degree of state security, they lack flexible allocation strategies for transaction types and execution environments, leading to delays in complex transaction processing, limited system throughput, and difficulty in balancing security and efficiency.

[0021] The third type relies on off-chain full node synchronization and a single state tree. This approach assumes that all transaction data can be fully synchronized and managed by a single state tree. However, as the amount of off-chain data increases or nodes change dynamically, the efficiency of verifying the correctness of state updates becomes low, posing potential security risks. Furthermore, it lacks a dynamic adjustment mechanism to balance scaling performance and decentralization.

[0022] To address this, the decentralized storage and hybrid Rollup scaling system and method provided in this application achieve efficient classification and processing of different types of transactions by introducing dynamically rotating DAC storage nodes and a ZK / OP aggregator allocation mechanism based on preset routing rules. By performing incremental state root commitment verification on the state update results in the sorter, incorrect state transitions can be identified and rejected in a timely manner, and suspicious tags can be added to prevent erroneous submissions to the main chain. Aggregation is performed using the KZG multinomial commitment algorithm to generate incremental state root commitments and aggregation proofs, improving state verification efficiency and overall system reliability. This application's solution not only significantly reduces on-chain storage costs and enhances the system's decentralization, but also ensures the availability and integrity of transaction data, achieving a balance between data availability, scaling efficiency, and system security. This supports stable operation in high-frequency trading and high-throughput scenarios, improving the overall performance, security, and operability of the system.

[0023] To better understand the above technical solutions, exemplary embodiments of this application will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application can be understood more clearly and thoroughly, and that the scope of this application can be fully conveyed to those skilled in the art.

[0024] Figure 1 This is a schematic diagram of a decentralized storage and hybrid Rollup scaling system according to an embodiment of this application. Figure 1 As shown, this decentralized storage and hybrid Rollup scaling system includes: DAC storage nodes are used to receive and store transaction data submitted by users; The DAC storage nodes are elected through a dynamically rotating data availability committee mechanism, which specifically includes: electing DAC storage nodes from candidate nodes based on the WRR algorithm; the elected DAC storage nodes register their public keys in the main chain and provide a data availability query interface; The candidate nodes are full nodes capable of synchronizing complete off-chain transaction data, and whose account root node hash value is consistent with the main chain account Merklegen. The full nodes are network nodes whose storage capacity meets preset requirements.

[0025] For example, suppose there are 10 full nodes in the candidate node pool, and each round of election needs to generate 3 DAC storage nodes. Weights are assigned to each candidate node according to the WRR (Weighted Round Robin) algorithm, for example, based on the node's storage capacity, online time, and reputation value: node 1 has a weight of 5, node 2 has a weight of 3, node 3 has a weight of 2, and so on. Through the WRR round-robin mechanism, nodes with higher weights have a higher probability of being selected, thus dynamically generating the list of DAC storage nodes for that round. The weights are recalculated for the next round of election, causing the DAC nodes to rotate continuously.

[0026] After election, Node A registers its public key in the main chain contract and opens an API interface for sorters, aggregators, or users to query data availability. For example, users or smart contracts can call the interface to verify whether transaction T1 is stored on Node A and obtain the transaction status or the corresponding Merkle proof. Assume that Node B has synchronized all off-chain transaction data before joining the candidate pool and calculated the root node hash of its account state tree as HB, which is consistent with the Merkle root of the main chain account. Thus, Node B can participate in the DAC election and, after being selected, store and provide off-chain transaction data. The system pre-determines that each full node must have at least 2TB of storage space and 1Gbps of network bandwidth to ensure the storage of historical transactions and rapid response to data query requests. Candidate nodes can only enter the DAC rotation mechanism after verifying that their node resources meet the requirements.

[0027] This application significantly improves the system's security, decentralization, and service reliability by setting up DAC storage nodes to receive and store user-submitted transaction data. A dynamically rotating data availability committee mechanism elects DAC nodes. Specifically, DAC storage nodes are dynamically elected from a candidate node pool using the WRR (Weighted Round Robin) algorithm. This ensures that nodes with high storage capacity, online stability, and good reputation are more likely to be selected, thus preventing a single node from monopolizing storage rights for extended periods and reducing the risk of malicious tampering or collusion. For example, if three DAC nodes are elected in each round of the candidate node pool, nodes with higher weights, such as node 1 (weight 5), have a higher probability of being selected. The weights are recalculated in the next round, allowing for continuous node rotation and achieving dynamic balance and decentralization of storage nodes. Furthermore, elected DAC nodes must register their public keys on the main chain and provide a data availability query interface, enabling the sorter, aggregator, and users to verify the integrity and availability of off-chain transaction data at any time. For example, after registering its public key, node A opens an API interface. Users or smart contracts can call this interface to verify whether transaction T1 is stored on node A and obtain the corresponding Merkle proof, thus ensuring the transparency and trustworthiness of data storage. Before participating in the election, candidate nodes must have the ability to synchronize complete off-chain transaction data and ensure that the hash of the root node of the account state tree is consistent with the main chain. For example, if node B has synchronized all off-chain transaction data and its state root is HB, consistent with the main chain, it can join the DAC rotation mechanism after meeting these conditions. Finally, by setting minimum resource requirements for candidate nodes, such as at least 2TB of storage space and 1Gbps network bandwidth, the system can ensure that each DAC node has sufficient capacity to store historical transaction data and quickly respond to data query requests. This not only guarantees the availability and integrity of off-chain data but also improves the overall throughput and scalability of the system, while maintaining the stability and efficient operation of the system even when nodes dynamically join or leave the network.

[0028] The system has at least one honest user who stores complete off-chain data in the form of SMT, which includes all historical transaction records and account status.

[0029] To illustrate with a specific example, suppose there is a node U in the system acting as an honest user. Node U maintains complete historical transaction data and account states off-chain, organizing them into an SMT (Simplified Mesh) structure. For instance, the leaf nodes of the account state tree store basic information for each account and the root hash of the account transaction index tree, the leaf nodes of the transaction index tree record the transaction hash value of that account, and the global transaction storage tree records all transaction metadata and state change summaries. When node U receives new transaction data, it updates its SMT state based on the transaction execution result, maintaining consistency with the main chain state tree. Due to the sparsity and hash proof properties of SMT, any state query or verification can be quickly completed using Merkle proofs without downloading or traversing the complete data, improving verification efficiency.

[0030] The technical solution of this application includes at least one honest user node, which stores complete off-chain data, including all historical transaction records and account states, in the form of a Sparse Merkle Tree (SMT). This technical feature significantly improves the overall performance and security of the system. First, the honest user node stores complete off-chain data, serving as an authoritative data source within the system. Even if other DAC nodes experience incomplete off-chain data due to failure, attacks, or data loss, the honest user node can still provide complete historical records, thus ensuring the verifiability and immutability of the overall system data and guaranteeing the integrity and trustworthiness of the off-chain data. Second, during state updates, the sorter and aggregator can verify the state based on the SMT data provided by the honest user. For example, during incremental state root commitment and aggregation proof generation, the honest user node can provide Merkle proofs of transaction or account states to verify the correctness of batch processing results, thereby reducing the risk of erroneous state submissions due to inconsistencies in off-chain data and effectively improving the reliability of state verification. Furthermore, the presence of the honest user node enhances the system's fault tolerance and security. Even in the face of malicious node attacks or partial node offline situations, the system can still rely on data provided by honest user nodes to ensure the availability and integrity of off-chain data. Combined with a dynamically rotating DAC storage node mechanism, even if some nodes malfunction, the data from honest user nodes can serve as a reference and verification standard, ensuring the stable operation of the entire Rollup scaling system under high load or high-risk environments. In summary, by ensuring at least one honest user node and storing complete off-chain data in SMT (Surface Mount Technology) format, the system not only enhances data integrity and security but also improves the reliability of state verification and overall fault tolerance, providing crucial support for the stable operation of decentralized storage and hybrid Rollup scaling systems under high throughput and complex transaction scenarios.

[0031] A sorter is used to obtain transaction data from the DAC storage node and allocate the transaction data to the ZK aggregator or OP aggregator according to preset routing rules. To illustrate, suppose the DAC storage node contains transactions T1 to T100. Some of these transactions involve only simple transfer operations, requiring no complex bytecode execution on the EVM, while others contain smart contract execution logic. The sorter analyzes the data fields of each transaction according to preset routing rules: if the transaction data does not contain EVM bytecode, it is assigned to the ZK aggregator for zero-knowledge batch processing; if the transaction data contains EVM bytecode, it is assigned to the OP aggregator for optimistic batch processing. By routing simple and complex transactions to different aggregators, the sorter avoids the performance bottleneck caused by processing all transactions in a single aggregator, improving overall throughput. Secondly, the ZK aggregator can generate zero-knowledge proofs for transactions without EVM bytecode, ensuring the correctness and immutability of the transactions; while the OP aggregator handles complex transactions, balancing execution efficiency and security through optimistic execution combined with a state verification mechanism. Furthermore, the sorter dynamically adjusts the routing strategy based on the transaction type to adapt to changes in transaction structure complexity, thereby supporting higher concurrency and diverse transaction scenarios. This not only improves the processing efficiency and throughput of the Rollup scaling system but also ensures the security and verification reliability of different types of transactions, providing key support for the stable operation of decentralized storage and hybrid Rollup systems in high-transaction-volume and high-complexity scenarios.

[0032] The ZK aggregator, which is communicatively connected to the sorter, is used to batch process the allocated transaction data and generate zero-knowledge processing results. The OP aggregator, which is communicatively connected to the sorter, is used to batch process the allocated transaction data and generate optimistic processing results. To illustrate, suppose the sorter distributes 100 transactions according to a preset routing rule: 70 transactions involve only simple transfers or queries, without containing EVM execution bytecode, and are assigned to the ZK aggregator for zero-knowledge batch processing; the remaining 30 transactions contain smart contract calls or complex transaction logic and are assigned to the OP aggregator for optimistic batch processing. In the ZK aggregator, zero-knowledge proofs are generated for batch transactions to ensure transaction validity without disclosing transaction details. For example, after batch processing T1 to T70, the ZK aggregator generates a zero-knowledge processing result containing a state update summary and the corresponding zero-knowledge proof, which can be verified by any network node, ensuring data immutability and privacy protection. In this way, even with a significant increase in the number of transactions, they can be efficiently submitted to the main chain while ensuring security and data privacy, significantly improving system throughput and scalability. In the OP aggregator, complex transactions containing EVM bytecode undergo optimistic batch processing. It first assumes the transactions are executed correctly and generates batch state update results, then performs final confirmation through state verification and incremental state root checking mechanisms. For example, after processing T71 to T100, an optimistic processing result is generated, and the correctness of the transaction state is verified by Merkle proof provided by the sorter or honest user node.

[0033] The DAC storage node is further configured to: update the state tree on the main chain based on the zero-knowledge processing result and / or the optimistic processing result, obtain the state update result, and send the state update result to the sorter; To illustrate, suppose in a transaction batch processing, the ZK aggregator generates a zero-knowledge processing result ZR, containing a summary of state changes from transaction T1 to T50; simultaneously, the OP aggregator generates an optimistic processing result OR. Upon receiving the zero-knowledge processing result ZR and the optimistic processing result OR, the DAC storage node merges the corresponding off-chain transaction data with the existing state tree to update the state tree on the main chain. For example, based on the SMT structure, the node updates the account state or global transaction summary of each transaction to the corresponding leaf node, while simultaneously generating a new Merkle root, forming a complete state update result. By calculating the transaction batch processing results returned by the aggregator, the DAC storage node can correctly map each off-chain transaction to the main chain state, thus avoiding state discrepancies caused by incomplete storage or calculation errors by some nodes. This ensures that all nodes in the system have a consistent understanding of the state tree, providing a reliable data foundation for the Rollup scaling system. Furthermore, it significantly improves the system's security and fault tolerance. Even in the event of anomalies in some aggregators or DAC nodes, the complete off-chain data and state information stored by honest user nodes in the system can serve as authoritative references, ensuring the correctness of state tree updates. Simultaneously, the sorter verifies the state update results generated by DAC nodes; if anomalies or suspicious updates are detected, they can be rejected from submission to the main chain, effectively preventing illegal states from being recorded and protecting against potential attacks or node failures. Furthermore, in terms of transaction processing efficiency, the centralized execution of state tree update operations by DAC nodes enables batch processing of zero-knowledge and optimistic transaction results, reducing the direct computational burden on the main chain and improving overall system throughput. At the same time, the state verification mechanism ensures the accuracy of batch processing results, enabling the system to operate stably even under high transaction volumes and complex transaction scenarios.

[0034] The sorter is also used to: check the state update result; if the state transition is found to be incorrect, reject the state transition and mark it as suspicious. Based on the KZG multinomial commitment algorithm, the state update results are aggregated to generate incremental state root commitments and aggregated proofs. Submit the incremental state root commitment and the aggregated proof to the main chain.

[0035] Suppose that after a round of transaction processing, the DAC storage node generates several state update results based on the batch processing results provided by the ZK aggregator and OP aggregator. Upon receiving these state update results, the sorter first verifies each update, for example, by comparing it with the Merkle proof in the incremental state tree to verify the correctness of the transaction execution. If a state update result is found to be inconsistent with the off-chain data or historical state provided by honest user nodes, the sorter will reject the update and mark it as suspicious, thus preventing erroneous or malicious states from being submitted to the main chain. This mechanism ensures the integrity and reliability of the entire system's state data, while providing early anomaly detection and protection capabilities. After verification, the sorter uses the KZG multinomial commitment algorithm to aggregate all valid state update results, generating incremental state root commitments and corresponding aggregate proofs. For example, for a batch of verified account balance updates, the sorter encodes these updates into a single polynomial using KZG commitments and generates corresponding aggregate proofs, ensuring that the correctness of the entire batch can be efficiently verified when submitted to the main chain, without needing to verify each transaction individually. Next, the sorter submits the incremental state root commitment and aggregate proof to the main chain, achieving secure updates to the on-chain state while significantly reducing the computational and storage pressure on the main chain.

[0036] Preferably, in some embodiments of this application, the state tree on the main chain adopts a sparse Merkle tree (SMT) structure, including: The account status tree has leaf nodes that store basic account information and embed the root node hash of the account transaction index tree. The account transaction index tree stores the transaction hash value of the corresponding account in its leaf nodes; The global transaction storage tree stores complete transaction records and summaries of state changes after transaction execution in its leaf nodes.

[0037] Specifically, assume there are multiple user accounts in the system, and each account executes several transactions off-chain. See also Figure 2The leaf nodes of the account state tree store basic account information, including balance, nonce value, and seqstate (sequence number), and also embed the hash of the corresponding transaction index tree root node (Tx index root). For example, the state node of account A records its balance as 100 and nonce as 5, and also embeds the transaction index tree root node HtxA. The leaf nodes of the account transaction index tree store the hash values ​​of all transactions for that account, used for indexing and fast verification. For example, the hash values ​​of transactions T1, T2, and T3 executed by account A are h1, h2, and h3, respectively. The transaction index tree root node HtxA is embedded in the leaf node of the account state tree, thus forming a nested relationship between the state tree and the transaction index tree. The leaf nodes of the global transaction storage tree store complete transaction records and summaries of state changes after transaction execution. For example, the leaf node of transaction T1 contains its complete transaction data and the account state change Delta1 after execution. The global transaction storage tree summarizes the transaction data of all accounts in the system, providing a final guarantee for the availability of Layer 2 data. Through the above methods, the system ensures the integrity and verifiability of off-chain data. Any user or smart contract can quickly verify whether an account state or transaction has been correctly recorded using Merkle proofs generated by SMT, without downloading the entire off-chain data, thereby reducing verification costs and improving system efficiency. Furthermore, because the account state tree and transaction index tree are nested, if any node attempts to tamper with transaction data, its corresponding Merkle root will mismatch. The sorter or aggregator can promptly detect anomalies, preventing illegal states from being submitted to the main chain and ensuring overall system security and data consistency.

[0038] Specifically, the account status tree is constructed based on the 160-bit address encoding standard, and the tree depth is fixed at 160 levels; The leaf nodes of the account status tree store basic account information, sorter cluster member status, DAC node identifier, and the root node hash of the account transaction index tree. The leaf nodes of the account transaction index tree store the Keccak256 hash value of the corresponding transaction; The leaf nodes of the global transaction storage tree store transaction metadata, numerical parameters, transaction execution final state identifier, transaction body hash fingerprint, and user signature.

[0039] Suppose that account A in the system executed three transactions T1, T2, and T3 off-chain. The account state tree is constructed based on the 160-bit address encoding standard, with a fixed depth of 160 levels. The leaf nodes of account A store its basic account information (such as balance and nonce), sorter cluster member status information, DAC node identifier, and the embedded root node HtxA of the account transaction index tree. The leaf nodes of account A's transaction index tree store the Keccak256 hash values ​​of the corresponding transactions; for example, T1, T2, and T3 correspond to h1, h2, and h3, respectively. The leaf nodes of the global transaction storage tree further store the metadata of each transaction (transaction type, timestamp), numerical parameters (amount, gas fees, etc.), transaction execution final state identifier (success or failure), transaction body hash fingerprint (used for quick verification of transaction integrity), and user signature. Through the 160-bit fixed-depth account state tree, any account and its transaction index can be quickly located, enabling efficient state verification and Merkle proof generation, while ensuring the sparsity of the structure and reducing storage overhead.

[0040] In the practical application of this application, the process of generating incremental state root commitments and aggregate proofs using the KZG polynomial commitment algorithm includes: In batch state changes, incremental state root commitments are calculated based on the original commitments and the updated commitments; Generate the corresponding quotient polynomial based on the node position weights of the sparse Merkle tree; Aggregate the quotient polynomials to obtain an aggregation proof.

[0041] Suppose the system contains accounts D, E, and F, which undergo transaction changes during a batch of transactions, resulting in changes to the leaf node states corresponding to their respective account state trees. The DAC storage node first records the original state root commitments and generates new state root commitments for the states after the batch state changes. Then, by calculating incremental state root commitments, the system can quickly generate incremental commitments for state updates only for the nodes that changed in this round, without recalculating the entire sparse Merkle tree, significantly improving computational efficiency. In this process, each node position in the sparse Merkle tree has a fixed weight, and these weights are used to calculate the corresponding quotient polynomial, representing the impact of the batch update on the entire state tree. Subsequently, the system aggregates these quotient polynomials to obtain a unified aggregated proof, which can be used to verify the correctness of the entire batch state change without generating independent proofs for each leaf node. This improves state verification efficiency. Through incremental state root commitments, the system only calculates for the changed state nodes, avoiding recalculation of the entire tree, which significantly reduces computational load and latency, especially in high-transaction-volume environments. Furthermore, it enhances system security and verifiability. Aggregate proofs, generated using the KZG multinomial commitment algorithm, provide a unified and unforgeable mathematical guarantee for batch state updates. This allows the sorter or main chain to quickly verify the correctness of state updates, and even if some nodes exhibit abnormal or malicious behavior, errors can be detected through the proofs. Finally, system throughput and storage efficiency are optimized. The incremental commitment and aggregate proof mechanism supports batch transaction processing and state verification, effectively reducing the amount of data submitted on-chain and verification overhead, while maintaining the integrity and immutability of state data. This supports the efficient and stable operation of decentralized storage and hybrid Rollup scaling systems under large-scale transaction and complex operation scenarios.

[0042] Preferably, the sorter distributes transaction data to the ZK aggregator or the OP aggregator according to a preset routing rule, wherein the routing rule is: The data field of the transaction data is obtained. If the data field does not contain bytecode executed on the EVM, the transaction data is assigned to the ZK aggregator. If a data field in the transaction data contains bytecode executed on the EVM, the transaction is assigned to the OP aggregator.

[0043] In detail, assuming the system receives two transactions: Transaction T1 is a regular transfer transaction, whose data field does not contain bytecode executed on the EVM; Transaction T2 is a smart contract call transaction, whose data field contains bytecode executed on the EVM. The sorter first parses the data field content of each transaction and determines the transaction type according to preset routing rules. For T1, since its data field does not contain EVM bytecode, the sorter assigns it to the ZK aggregator, which performs zero-knowledge batch processing to generate the processing result and state update commitment. For T2, since its data field contains EVM bytecode, the sorter assigns it to the OP aggregator, which performs optimistic batch processing to generate the corresponding state update and challengeable proof. By distinguishing whether or not EVM bytecode is contained, this embodiment of the application allows the sorter to delegate ordinary transactions that do not require complex calculations to the efficient ZK aggregator, while complex contract transactions are handled by the OP aggregator, fully leveraging the computational advantages of different aggregators and improving overall processing efficiency. Secondly, by splitting the traffic, the ZK aggregator and the OP aggregator can work in parallel, avoiding the bottleneck caused by a single aggregator handling all transactions, thus maintaining stable system operation under high transaction volume environments. In addition, the ZK aggregator can perform zero-knowledge verification on ordinary transactions to ensure the correctness of state updates; the OP aggregator provides an optimistic verification mechanism for complex EVM transactions and supports challengeable processes to ensure the security and transparency of smart contract execution.

[0044] In some embodiments of this application, the process by which the sorter verifies the state update result includes: Based on the state update result provided by the DAC storage node, the corresponding incremental state root commitment is calculated, and the calculated incremental state root commitment is compared with the state root in the state update result. When the calculated incremental state root commitment is inconsistent with the state root in the state update result, the state transition is determined to be incorrect, the state transition is rejected, and the state transition is marked as suspicious.

[0045] For example, suppose a DAC storage node in the system submits a batch of transaction state update results based on the aggregator and generates corresponding incremental state root commitments. Upon receiving these state update results, the sorter first recalculates the incremental state root commitments corresponding to this batch of transactions based on the transaction data and state change information provided by the DAC node. Then, the sorter compares the calculated incremental state root commitments with the state roots in the state update results submitted by the DAC node. If they match, the state transition is correct, and the sorter allows the state update to be submitted to the main chain; if they do not match, the state transition is deemed abnormal or erroneous, the sorter rejects the state transition, and marks the state update as suspicious for subsequent review or challenge by the system. This embodiment of the application, through the independent calculation and comparison of incremental state root commitments, enables the sorter to promptly detect erroneous state submissions caused by aggregator calculation errors, DAC node anomalies, or potential attacks, thereby preventing incorrect states from being written to the main chain and maintaining the credibility of the entire system. Secondly, it enhances system security and defense capabilities. Even if some DAC nodes or aggregators exhibit malicious behavior or malfunctions, the sorter's verification mechanism can promptly mark abnormal states, providing a basis for subsequent error correction and challenges, thereby reducing the risk of the system being attacked or entering erroneous states. Furthermore, by labeling suspicious states instead of directly overwriting them, the system can retain audit trails when abnormal states occur, while allowing honest nodes or users to participate in challenges or verifications, ensuring the stable operation of the Rollup scaling system in complex transaction and high-concurrency environments.

[0046] In other embodiments of this application, candidate storage nodes in the Layer 2 Data Committee (DAC) system, in addition to synchronizing complete off-chain data, must register their public keys in the smart contract and provide publicly accessible interfaces for querying, as well as the state update interfaces required by the sorter. For example, in practical applications, after a batch of transactions is completed, the sorter needs to verify the off-chain data state of the candidate nodes. If the data is found to be inconsistent with the hash value of the root node of the on-chain account, the node will be deemed unqualified and unable to participate in subsequent storage and verification. This mechanism effectively prevents data nodes from acting maliciously or providing incomplete data, thereby ensuring the data consistency and availability of the entire Layer 2 network. Furthermore, in other embodiments of this application, the root node of each account's transaction index tree is embedded in the account field. The leaf nodes store the Keccak 256 hash value of the account's transactions, rather than the complete transaction record, to reduce storage duplication overhead. The global transaction storage tree stores the complete transaction record since the genesis block. Each leaf node not only records the original transaction data but also includes a summary of the state changes after the transaction execution. This tiered storage reduces node storage pressure and off-chain data synchronization overhead, while ensuring the historical verifiability of any transaction and improving system throughput and response speed.

[0047] When submitting state changes to the main chain, each node generates a root commitment using KZG polynomial commitments and generates a quotient polynomial for each modified value, which is then aggregated to generate the final proof. The binding nature of KZG commitments ensures that the commitments only reflect the true changes in node data, and salting out transactions prevents forgery. For example, if a batch of transactions involves state changes for multiple accounts, nodes only need to generate incremental commitments for the modified leaf nodes, merging them into a single aggregated proof submitted to the chain. Validators do not need to store the complete state to confirm the validity of the update, significantly reducing on-chain storage and verification complexity while providing high security and anti-forgery capabilities, making on-chain verification resource consumption controllable.

[0048] Furthermore, to further improve transaction processing performance and data availability in this system, the orderer can dynamically adjust the transaction allocation ratio between zero-knowledge (ZK) aggregators and optimistic (OP) aggregators based on the current network load and the available computing power of each aggregator. For example, when the system detects that the processing capacity of the OP aggregator is limited, and a large number of basic transfer transactions do not involve complex contracts, the orderer can allocate more transactions to the ZK channel to achieve a balance in overall processing throughput. This dynamic allocation mechanism can avoid overloading or idle resources in a single channel, thereby significantly improving the overall processing efficiency and response speed of the system.

[0049] During the transaction state update process, the sorter rigorously verifies the generated state update results, ensuring the validity of the aggregated proof by comparing the incremental state root commitment with the previous state root commitment already stored in the main chain. If an aggregated proof fails verification, the sorter marks the batch of transactions as an abnormal batch and suspends the submission operation. For example, in a batch submission, if some transaction data results in inconsistent incremental state roots due to storage node failure or malicious tampering, the batch will be immediately suspended to prevent erroneous states from being submitted to the main chain. This mechanism effectively ensures the accuracy and security of on-chain data and prevents the propagation of erroneous or malicious states.

[0050] Furthermore, to ensure consistency between the ZK and OP channels in the hybrid Rollup architecture, DAC storage nodes compare the two types of processing results when generating state update results. If discrepancies are found, the system selects a trustworthy result based on a node reputation weighting strategy and records the corresponding weight information on the blockchain for subsequent verification. For example, if a transaction's state change in the ZK processing channel conflicts with the result in the OP channel, the system determines the final trustworthy state based on each node's historical behavior and reputation score. This mechanism effectively avoids data conflicts between different channels, ensuring the consistency and availability of system data. To support the aforementioned reputation weighting mechanism, the system also includes a reputation evaluation module for comprehensive evaluation of DAC storage nodes. Evaluation metrics include historical data availability proof, transaction submission success rate, and state update accuracy. Based on these metrics, a node reputation score is calculated and used as the basis for node selection weight during the dynamically rotating data availability committee election process. For example, nodes that consistently provide high-quality data services will have a higher probability of being selected, while nodes that frequently time out or engage in malicious behavior will have their selection weight reduced. Through this mechanism, the system not only improves the controllability of node behavior, but also incentivizes nodes to actively maintain data integrity, thereby enhancing the long-term stability and security of the system.

[0051] On the other hand, embodiments of this application also provide a decentralized storage and hybrid Rollup scaling method, which is executed by the aforementioned decentralized storage and hybrid Rollup scaling system.

[0052] The decentralized storage and hybrid Rollup scaling system described in this application achieves efficient, secure, and verifiable Layer 2 network data processing through the close collaboration of DAC storage nodes, a sorter, ZK aggregator, and OP aggregator. First, DAC storage nodes receive and store user-submitted transaction data and update the state tree on the main chain in the form of an SMT structure. They submit the state update results to the chain via incremental state root commitments and aggregation proofs, ensuring the complete preservation of transaction data off-chain. Simultaneously, the incremental submission method reduces on-chain storage overhead and improves system throughput. Second, the sorter not only allocates transaction data to ZK aggregators or OP aggregators according to preset routing rules, enabling separate processing of basic transfer transactions and complex smart contract transactions, but also rigorously verifies the state update results generated by the DAC storage nodes after the state update is completed. By calculating the incremental state root commitment and comparing it with the submitted state root, the system can promptly identify inconsistent or abnormal states and label them as suspicious, thereby preventing erroneous or malicious states from being uploaded to the chain. This mechanism ensures the consistency and trustworthiness of off-chain data and on-chain states, providing strong protection for network security. Furthermore, this application employs a Sparse Merkle Tree (SMT) structure to construct the account state tree, account transaction index tree, and global transaction storage tree. The depth of the account state tree is fixed using a 160-bit address encoding standard, ensuring a constant verification path length for each transaction and avoiding the uncertainty of verification overhead inherent in traditional variable-depth Merkle trees when accounts are sparse or unevenly distributed. The leaf nodes of the account state tree not only store basic account information but also embed the hash and sorter of the transaction index tree root node and the state information of the DAC node, enabling efficient indexing and verification of each account's transaction behavior and state changes. The global transaction storage tree stores complete transaction records and state change summaries, and utilizes the single-path modification characteristic of SMT to achieve incremental updates, further improving data availability and system throughput. In terms of transaction processing, by distributing transaction data to either a ZK aggregator or an OP aggregator, the system can optimize the processing flow for different types of transactions. The ZK aggregator processes transactions without EVM bytecode, generating compact zero-knowledge proofs and reducing hardware resource requirements; the OP aggregator processes complex transactions containing EVM bytecode, ensuring the completeness of smart contract execution. This channel-based strategy, combined with the dynamic scheduling of the orderer, enables the system to maintain high throughput and low latency under heterogeneous transaction loads, while ensuring the finality and verifiability of state changes. Finally, by generating incremental state root commitments and aggregate proofs using the KZG multinomial commitment algorithm, and combining this with the orderer's verification mechanism, the system prevents data forgery and illegal state submissions, achieving highly reliable off-chain data verification and on-chain state commitments. This design not only enhances the security and stability of the entire system but also improves processing efficiency, reduces costs, and ensures the availability and consistency of off-chain data through the organic combination of incremental submissions, channel-based processing, and verification mechanisms.In summary, this application's solution achieves a highly efficient, secure, and verifiable decentralized storage and hybrid Rollup scaling system by combining complete data preservation of DAC storage nodes, intelligent routing and verification by the sorter, channel-specific processing by ZK and OP aggregators, and SMT structure with KZG incremental commitment mechanism. This significantly improves the throughput, reliability, and anti-malicious capabilities of the Layer 2 network, balancing performance and security, and meeting the practical needs of large-scale transaction processing and cross-layer state consistency verification.

[0053] In the description of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0054] In this application, unless otherwise expressly specified and limited, "above" or "below" the second feature can mean that the first and second features are in direct contact, or that they are in indirect contact through an intermediate medium. Furthermore, "above," "on top of," and "over" the second feature can mean that the first feature is directly above or diagonally above the second feature, or simply that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature can mean that the first feature is directly below or diagonally below the second feature, or simply that the first feature is at a lower horizontal level than the second feature.

[0055] In the description of this specification, the terms "one embodiment," "some embodiments," "embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0056] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make modifications, alterations, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A decentralized storage and hybrid Rollup expansion system, characterized in that, include: DAC storage nodes are used to receive and store transaction data submitted by users; A sorter is used to obtain transaction data from the DAC storage node and allocate the transaction data to the ZK aggregator or OP aggregator according to preset routing rules. The ZK aggregator, which is communicatively connected to the sorter, is used to batch process the allocated transaction data and generate zero-knowledge processing results. The OP aggregator, which is communicatively connected to the sorter, is used to batch process the allocated transaction data and generate optimistic processing results. The DAC storage node is further configured to: update the state tree on the main chain based on the zero-knowledge processing result and / or the optimistic processing result, obtain the state update result, and send the state update result to the sorter; The sorter is also used to: check the state update result; if the state transition is found to be incorrect, reject the state transition and mark it as suspicious. Based on the KZG multinomial commitment algorithm, the state update results are aggregated to generate incremental state root commitments and aggregated proofs. Submit the incremental state root commitment and the aggregated proof to the main chain; The sorter allocates transaction data to the ZK aggregator or the OP aggregator according to preset routing rules, which are as follows: The data field of the transaction data is obtained. If the data field does not contain bytecode executed on the EVM, the transaction data is assigned to the ZK aggregator. If any data field in the transaction data contains bytecode executed on the EVM, then the transaction is assigned to the OP aggregator. The process by which the sorter verifies the state update result includes: Based on the state update result provided by the DAC storage node, the corresponding incremental state root commitment is calculated, and the calculated incremental state root commitment is compared with the state root in the state update result. When the calculated incremental state root commitment is inconsistent with the state root in the state update result, the state transition is determined to be incorrect, the state transition is rejected, and the state transition is marked as suspicious.

2. The decentralized storage and hybrid Rollup expansion system according to claim 1, characterized in that, The DAC storage nodes are elected through a dynamically rotating data availability committee mechanism, specifically including: DAC storage nodes are elected from candidate nodes based on the WRR algorithm; The selected DAC storage node registers its public key in the main chain and provides a data availability query interface; The candidate node is a full node that can synchronize complete off-chain transaction data and whose account root node hash value is consistent with the main chain account Merklegen.

3. The decentralized storage and hybrid Rollup expansion system according to claim 2, characterized in that, The full node is a network node whose storage capacity meets the preset requirements.

4. The decentralized storage and hybrid Rollup expansion system according to claim 3, characterized in that, The system has at least one honest user who stores complete off-chain data in the form of SMT, which includes all historical transaction records and account status.

5. The decentralized storage and hybrid Rollup expansion system according to claim 4, characterized in that, The state tree on the main chain adopts a sparse Merkle tree (SMT) structure, including: The account status tree stores basic account information in its leaf nodes and embeds the root node hash of the account transaction index tree. The account transaction index tree stores the transaction hash value of the corresponding account in its leaf nodes; The global transaction storage tree stores complete transaction records and summaries of state changes after transaction execution in its leaf nodes.

6. The decentralized storage and hybrid Rollup expansion system according to claim 5, characterized in that: The account status tree is constructed based on the 160-bit address encoding standard, and the tree depth is fixed at 160 levels. The leaf nodes of the account status tree store basic account information, sorter cluster member status, DAC node identifier, and the root node hash of the account transaction index tree. The leaf nodes of the account transaction index tree store the Keccak256 hash value of the corresponding transaction; The leaf nodes of the global transaction storage tree store transaction metadata, numerical parameters, transaction execution final state identifier, transaction body hash fingerprint, and user signature.

7. The decentralized storage and hybrid Rollup expansion system according to claim 6, characterized in that, The process of generating incremental state root commitments and aggregate proofs using the KZG polynomial commitment algorithm includes: In batch state changes, incremental state root commitments are calculated based on the original commitments and the updated commitments; Generate the corresponding quotient polynomial based on the node position weights of the sparse Merkle tree; Aggregate the quotient polynomials to obtain an aggregation proof.

8. A decentralized storage and hybrid Rollup expansion method, characterized in that, The method is performed by the decentralized storage and hybrid Rollup scaling system described in any one of claims 1-7.

Images