An interval learning type authentication shard state storage system for alliance chain

Abstract

The application discloses a kind of interval learning type authentication fragmented state storage systems for alliance chain, specifically relates to state storage technical field, including global state root layer is used to aggregate all committee authentication root, and global state root of write-in block header is generated;Committee authentication layer is used to aggregate all interval descriptors managed by the committee, and committee authentication root is generated;Interval description and routing layer is used to maintain the mapping relationship between state address, address interval, storage instance and committee;Interval learning type authentication storage instance layer is used to maintain the state data and historical version in corresponding address interval;Bottom learning type authentication storage engine layer is used to organize state version according to composite key, and generate local integrity proof.The system of the application divides global state address space into multiple continuous and mutually non-overlapping address intervals, and each address interval is responsible by an interval learning type authentication storage instance.

Description

Technical Field

[0001] This invention relates to the field of state storage technology, specifically to a segmented learning-based authentication sharded state storage system for consortium blockchains. Background Technology

[0002] As consortium blockchain systems operate over time, on-chain state data and its historical versions accumulate continuously. For consortium blockchains that support smart contracts or complex business logic, the on-chain state includes not only account balances but also account information, contract variables, business records, and cross-organizational collaboration data. The same state address can generate multiple historical versions at different block heights; therefore, the state storage system needs to support not only current state queries but also historical state queries and integrity verification.

[0003] Existing consortium blockchain sharded state storage solutions typically reduce the storage pressure on individual committees by dividing the global state address space among different committees or shards. However, within each shard, state data usually still relies on tree-structured authentication indexes such as Merkle Tree, Merkle B+ Tree, and Merkle Patricia Trie for organization. While these structures can generate state roots and query proofs, they require maintaining a large number of explicit tree nodes, hash paths, and historical index nodes in long-term operation and frequent update scenarios, easily leading to high storage redundancy.

[0004] Existing learning-based state storage solutions can reduce the overhead of single-node state storage through columnar layout and learning indexes. However, these solutions are typically geared towards single-node complete state storage and lack address range partitioning, range ownership descriptions, committee affiliation relationships, and global state root authentication mechanisms in sharded environments. Therefore, a simple local learning storage root can only prove that data belongs to a certain local storage structure, but cannot prove whether that storage structure is legally responsible for the range containing the target address under the current system configuration.

[0005] Furthermore, in a sharded system, the state size and access load of different address ranges may change over time. If a range continues to grow, the system needs to be able to split it into multiple smaller ranges; if adjacent ranges have low load for a long period, the system also needs to be able to merge them to reduce the number of instances and metadata overhead. However, if the splitting is done directly according to the physical file location or the midpoint of the data volume, different historical versions of the same state address may be split into different instances, thereby disrupting historical query semantics and authentication semantics.

[0006] Therefore, existing interval-based learning-based authentication sharded state storage systems have the following technical problems: (1) The tree-structured authentication index has high storage redundancy. Traditional Merkle-type authentication indexes require maintaining explicit tree nodes, pointer relationships, and multi-level hash paths. When the state is frequently updated and historical versions need to be retained, older version index nodes cannot be deleted immediately, which can easily lead to a continuous increase in the index storage size.

[0007] (2) Single-node learning storage lacks sharding semantics Existing learning-based state storage schemes can prove that a certain state version belongs to the local state root, but they cannot prove which address range the local state root corresponds to, nor can they prove which committee is currently responsible for that range.

[0008] (3) Lack of regional ownership certification In a sharded system, the client not only needs to verify that the data has not been tampered with, but also needs to verify that the storage instance returning the data is indeed responsible for the range where the target address lies. Existing single-node storage roots cannot express this range affiliation.

[0009] (4) Lack of a global authentication loop A sharded system contains multiple committees and multiple storage instances. If only a local state root exists, the client cannot verify the query result to the global state root, nor can it determine whether the result is committed by the current block header.

[0010] (5) Directly splitting learning storage instances may disrupt historical queries. Learning-oriented state storage typically organizes multiple historical versions of the same state address consecutively or in an ordered manner. If it is split directly according to the point in the physical file or the midpoint of the data volume, different historical versions of the same address may be split into different instances, causing historical queries to need to be completed across instances and breaking local authentication semantics.

[0011] (6) Lack of a mechanism for merging adjacent intervals If multiple adjacent intervals are in a low-load state for a long time and cannot be merged, the number of storage instances in the system will continue to increase, and the maintenance costs of routing tables, interval descriptors and authentication trees will rise. Summary of the Invention

[0012] To address the aforementioned technical problems, this invention provides a segmented learning-based authentication sharded state storage system for consortium blockchains. This system enables the system to reduce local state storage overhead while supporting state routing, historical querying, segment ownership authentication, global state authentication, and segment splitting / merging in a sharded environment.

[0013] To achieve the above objectives, the present invention provides the following technical solution: A segmented learning-based authentication sharding state storage system for consortium blockchains includes a global state root layer for aggregating all committee authentication roots and generating a global state root that is written to the block header. The committee authentication layer is used to aggregate all range descriptors managed by the committee and generate the committee authentication root; The range description and routing layer are used to maintain the mapping relationship between state addresses, address ranges, storage instances, and committees; The range-based learning-type authentication storage instance layer is used to maintain the status data and historical versions within the corresponding address range; The underlying learning-based authentication storage engine layer is used to organize state versions according to composite keys and generate local integrity certificates.

[0014] In a preferred embodiment, the state data in the interval-based learning-based authentication storage instance layer includes a state address and a state value, and the composite key in the underlying learning-based authentication storage engine layer consists of a state address and a block height.

[0015] In a preferred embodiment, the interval-based learning-type authentication storage instance layer includes a write cache layer for receiving newly written state versions; The ordered state data file layer is used to store state versions sorted according to composite keys; The learned index file layer is used to predict the location of the target state version based on the composite key; The authentication file layer is used to generate local integrity certificates; The local state root generation module is used to generate the local state root for this instance.

[0016] In a preferred embodiment, the interval description and the interval descriptor in the routing layer bind the local state root to the address interval affiliation in the sharding environment. The routing table is used to locate the target address interval, target storage instance and its affiliated committee based on the state address. The data in the routing table needs to be updated if one or more of the following changes occur: a new address interval is added, an address interval is split, adjacent address intervals are merged, the local state root corresponding to the interval changes, or the interval mapping version changes.

[0017] In a preferred embodiment, the step of splitting the address range is as follows: S1. The system checks whether the target instance meets the splitting conditions; S2. The system selects the split boundary based on address distribution, number of states, or access load; S3. The system guarantees that the address boundaries are complete. S4. The system creates a left instance and a right instance; S5. The system assigns the status version in the original instance to the corresponding new instance according to the status address; S6. Rebuild or update the learning index files for both the left and right instances; S7. The left and right instances each generate local authentication files; S8. The left instance and the right instance each generate a new local state root; S9. The system generates two new interval descriptors; S10. System updates routing table; S11. System Update Committee Certification Root; S12. System updates global state root.

[0018] In a preferred embodiment, the step of merging adjacent address ranges is as follows: S1. The system checks whether two adjacent instances meet the merge conditions; S2. The system confirms that the address ranges of the two instances are continuous and do not overlap; S3. The system creates a new merge instance; S4. The system reads the state versions from the two original instances; S5. The system merges state versions in an orderly manner according to the composite key; S6. The system generates a new ordered state data file; S7. The system generates a new learning index file; S8. The system generates a new authentication file; S9. The system calculates the local state root of the new instance; S10. The system generates a new interval descriptor; S11. The system deletes or discards the original two range descriptors; S12. System updates routing table; S13. System Update Committee Certification Root; S14. System updates global state root.

[0019] In a preferred embodiment, the interval-based learning-type authentication storage instance layer adopts a three-level authentication structure, including local storage authentication, interval ownership authentication, and global state authentication.

[0020] In a preferred embodiment, the local storage authentication is used to prove that the query result does indeed belong to a certain interval-based learning-type authentication storage instance. The verification end reconstructs the local state root based on the query result and the local proof. If the reconstructed local state root is equal to the local state root of the interval-based storage instance recorded in the interval descriptor, it indicates that the query result belongs to the corresponding instance.

[0021] In a preferred embodiment, the interval ownership authentication is used to prove that the target state address does indeed belong to the address interval that the instance is responsible for, and that the instance's local state root is committed by the interval descriptor. The verification end verifies whether the state address is in the interval descriptor, and at the same time verifies whether the interval descriptor is committed by the committee-certified root. If the verification passes, it means that the storage instance is legally responsible for the interval where the target address is located under the current mapping version.

[0022] In a preferred embodiment, the global state authentication is used to prove that the committee authentication root belongs to the global state root. The system aggregates all committee authentication roots to generate a global state root and writes the global state root into the block header or global state commitment. The verification end verifies whether the target committee authentication root is committed by the global state root through global proof. If the final global state root is consistent with the state root in the block header, the query result verification is successful.

[0023] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention transforms the learning-type authentication state storage structure into a local storage instance oriented towards a continuous address range, so that each instance is only responsible for the state and its historical version within one address range. 2. This invention uses the state address and block height as a composite key to organize state versions, enabling multiple historical versions of the same state address to be stored continuously or in order, thereby supporting historical state queries. 3. This invention binds address range boundaries, instance numbers, committee numbers, mapping versions, and local state roots using range descriptors, enabling local state roots to have range ownership semantics; 4. This invention constructs a three-level authentication path of "local storage authentication - interval ownership authentication - global state authentication", enabling query results to be verified from the local state root to the global state root; 5. When splitting interval-based storage instances, this invention uses the complete state address as the split boundary to ensure that all historical versions of the same state address are not split into different instances. It also performs ordered merging of storage instances corresponding to two adjacent consecutive address intervals to generate new storage instances, local state roots, and interval descriptors. This avoids unbounded growth and frequent adjustments in the number of instances. Attached Figure Description

[0024] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a schematic diagram of the overall system framework of the present invention; Figure 2 This is a schematic diagram of the three-level authentication structure of the present invention; Figure 3This is a schematic diagram of the access process structure of the present invention; Figure 4 This is a schematic diagram of the split and merged structure of the present invention.

[0025] In the diagram: 1. Global State Root Layer; 2. Committee Authentication Layer; 3. Range Description and Routing Layer; 4. Range-based Learning Authentication Storage Instance Layer; 5. Underlying Learning Authentication Storage Engine Layer. Detailed Implementation

[0026] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] Please see Figure 1 The present invention provides the following technical solution: A segmented learning-based authentication sharding state storage system for consortium blockchains includes a global state root layer 1 for aggregating all committee authentication roots and generating a global state root to be written into the block header. Committee authentication layer 2 is used to aggregate all range descriptors managed by the committee and generate the committee authentication root; The range description and routing layer 3 are used to maintain the mapping relationship between state addresses, address ranges, storage instances, and committees; The interval-based learning-type authentication storage instance layer 4 is used to maintain the status data and historical versions within the corresponding address interval; The underlying learning-based authentication storage engine layer 5 is used to organize state versions according to composite keys and generate local integrity certificates.

[0028] In a preferred embodiment, the state data in the interval-based learning-based authentication storage instance layer 4 includes a state address and a state value, and the composite key in the underlying learning-based authentication storage engine layer 5 consists of a state address and a block height. Specifically, the state data in the system is represented as follows: <addr, value> Here, addr represents the state address, and value represents the state value.

[0029] When the state is written to or updated at a certain block height, the system generates a state version: <addr, blk, value> Here, blk represents the block height.

[0030] In the underlying learning-based authentication storage engine, the system uses a composite key consisting of the state address and the block height: K =<addr, blk> .

[0031] This composite key is used to uniquely identify the version of a state address at a certain block height. Through this composite key, multiple historical versions of the same state address can be logically organized consecutively or in an ordered manner, thus supporting historical state queries.

[0032] In a preferred embodiment, the interval-based learning-type authentication storage instance layer 4 includes a write cache layer for receiving newly written state versions; The ordered state data file layer is used to store state versions sorted according to composite keys; The learned index file layer is used to predict the location of the target state version based on the composite key; The authentication file layer is used to generate local integrity certificates; The local state root generation module is used to generate the local state root for this instance.

[0033] For current or historical state queries, the instance returns the query results and local proof. The client or verification module can then reconstruct the local state root based on the query results and local proof to verify whether the data belongs to that instance.

[0034] In a preferred embodiment, the interval description and the interval descriptor in the routing layer 3 bind the local state root to the address interval affiliation in the sharding environment. The routing table is used to locate the target address interval, target storage instance and its affiliated committee based on the state address. The data in the routing table needs to be updated if one or more of the following changes occur: a new address interval is added, an address interval is split, adjacent address intervals are merged, the local state root corresponding to the interval changes, or the interval mapping version changes.

[0035] In practical use, the system divides the global state address space into multiple contiguous address ranges. Each address range is represented as: Ii = [Li, Ui) Where Li is the left boundary of the address range and Ui is the right boundary of the address range.

[0036] The address range must meet the following requirements: 1. All address ranges collectively cover the global address space; 2. No two address ranges overlap; 3. Any state address belongs to only one address range at any given time; 4. Each address range is managed by a range-based learning-based authentication storage instance.

[0037] Each interval-based learning-based authentication storage instance is represented as: Instancei : [Li, Ui) This instance is responsible for storing all states and their historical versions whose addresses fall within the range [Li, Ui).

[0038] The interval descriptor is represented as: Di =<Li, Ui, InstanceIDi, CommitteeIDi, Epochi, R_local_i> in: Li represents the left boundary of the address range; Ui represents the right boundary of the address range; InstanceID_i represents the interval-based learning-type authentication storage instance number; CommitteeID_i represents the committee number responsible for this interval; Epoch_i represents the range mapping version; R_local_i represents the current local state root of this instance.

[0039] The purpose of a range descriptor is to bind the following information together: Address range + storage instance + committee + mapping version + local state root.

[0040] Using the range descriptor, the system can prove that a certain local state root not only exists, but also that the storage instance corresponding to the local state root is legally responsible for the range where the target address is located under the current mapping version.

[0041] For any access request, the system first reads the status address addr, and then searches the routing table for a range that meets the following conditions: addr ∈ [Li, Ui) Upon reaching the target range, the system determines the corresponding range-based learning-type authentication storage instance Instance_i and committee Committee_i.

[0042] like Figure 4 As shown, in a preferred embodiment, when the number of states, the number of historical versions, the storage capacity, or the access load of a certain interval-based learning-type authentication storage instance exceeds a preset threshold, the system can trigger a split operation. Let the instance to be split be: Instance_i : [Li, Ui) The system selects a split boundary M to split the original interval into two consecutive sub-intervals: [Li, M) [M, Ui) The split boundary M must satisfy the complete address boundary principle, which means that different historical versions of the same state address must not be split into different instances.

[0043] After splitting, two new storage instances are generated: Instance_left : [Li, M) Instance_right : [M, Ui) For any state version: <addr, blk, value> like: addr ∈ [Li, M) This state version then belongs to the left instance; like: addr ∈ [M, Ui) This state version then belongs to the right instance.

[0044] The steps for splitting the address range are as follows: S1. The system checks whether the target instance meets the splitting conditions; S2. The system selects the split boundary M based on address distribution, number of states, or access load; S3. The system guarantees that M is a complete address boundary; S4. The system creates a left instance and a right instance; S5. The system assigns the status version in the original instance to the corresponding new instance according to the status address; S6. Rebuild or update the learning index files for both the left and right instances; S7. The left and right instances each generate local authentication files; S8. The left instance and the right instance each generate a new local state root; S9. The system generates two new interval descriptors; S10. System updates routing table; S11. System Update Committee Certification Root; S12. System update global state root In a preferred embodiment, when two adjacent interval-based learning authentication storage instances are in a low-load state for a long time, or when the system needs to reduce the number of instances and metadata maintenance overhead, a merge operation can be triggered.

[0045] Suppose the two instances to be merged are: Instance_a : [L, M) Instance_b : [M, U) Since the two intervals are adjacent and continuous, the system can merge them into: Instance_new : [L, U).

[0046] The steps for merging adjacent address ranges are as follows: S1. The system checks whether two adjacent instances meet the merge conditions; S2. The system confirms that the address ranges of the two instances are continuous and do not overlap; S3. The system creates a new merge instance; S4. The system reads the state versions from the two original instances; S5. The system merges state versions in an orderly manner according to the composite key; S6. The system generates a new ordered state data file; S7. The system generates a new learning index file; S8. The system generates a new authentication file; S9. The system calculates the local state root of the new instance; S10. The system generates a new interval descriptor; S11. The system deletes or discards the original two range descriptors; S12. System updates routing table; S13. System Update Committee Certification Root; S14. System updates global state root.

[0047] To avoid frequent splitting and merging of the system under critical conditions, this invention sets different splitting and merging thresholds.

[0048] For example: When the state size or access load of an instance exceeds the splitting threshold, the system triggers a splitting operation; when the state size or access load of an adjacent instance is below the merging threshold, the system triggers a merging operation.

[0049] The system can also set the following constraints for each split or merge: 1. The maximum number of states for a single instance; 2. Maximum storage capacity of a single instance; 3. Maximum access load for a single instance; 4. Minimum address range width; 5. Minimum number of states; 6. Maximum number of instances; 7. Minimum time interval for splitting / merging.

[0050] The above control strategies can prevent the number of instances from growing uncontrollably and can also prevent system instability caused by frequent splitting and merging.

[0051] like Figure 2 As shown, in a preferred embodiment, the interval-based learning-type authentication storage instance layer 4 adopts a three-level authentication structure, including local storage authentication, interval ownership authentication, and global state authentication.

[0052] In a preferred embodiment, the local storage authentication is used to prove that the query result indeed belongs to a certain range-based learning-type authentication storage instance. When a user queries the status, the target instance returns: result, Proof_local Where `result` represents the query result, and `Proof_local` represents the local proof. The verification end reconstructs the local state root based on the query results and local proof. If the reconstructed local state root is equal to the local state root of the interval storage instance recorded in the interval descriptor, it means that the query result belongs to the corresponding instance.

[0053] In a preferred embodiment, the interval ownership authentication is used to prove that the target state address does indeed belong to the address interval responsible for the instance, and that the instance's local state root is committed by the interval descriptor. The verification end needs to check... addr ∈ [Li, Ui) At the same time, it verifies whether the range descriptor has been certified by the committee's root commitment. If the verification passes, it means that the storage instance is legally responsible for the range where the target address is located under the current mapping version.

[0054] In a preferred embodiment, the global state authentication is used to prove that the committee authentication root belongs to the global state root. The system aggregates all committee authentication roots to generate a global state root and writes the global state root into the block header or global state commitment. The verification end verifies whether the target committee authentication root is committed by the global state root through global proof. If the final global state root is consistent with the state root in the block header, the query result verification is successful.

[0055] like Figure 3 As shown, the access process is as follows: The write process is used to handle state update requests. A write request is represented as: Put(addr, value) The specific steps are as follows: 1. The system receives a write request Put(addr, value); 2. The system queries the routing table based on addr; 3. The routing table returns the address range [Li, Ui) containing this address; 4. The system determines the target range-based storage instance Instance_i; 5. The system reads the current block height blk; 6. System Generation Status Version<addr, blk, value> ; 7. The target instance writes this state version to the underlying learning-based authentication storage engine; 8. The target instance updates its local state root R_local_i; 9. The system updates the local state root in the corresponding interval descriptor; 10. The committee certification layer recalculates the committee certification root; 11. Recalculate the global state root at the global state root level; 12. A new global state root is written to the block header or global state commitment.

[0056] The current status query process is as follows: The current status query request is represented as: Get(addr) The specific steps are as follows: 1. The system receives a current status query request (Get(addr)); 2. The system queries the routing table based on addr; 3. Locate the range [Li, Ui] containing this address in the routing table; 4. The system determines the target storage instance Instance_i; 5. The target instance looks up the latest status version at the status address; 6. The target instance returns the current state value and local proof; 7. Supplementary proof of ownership for the authentication layer; 8. The authentication layer supplements global state proof; 9. The system returns the query results and combined proofs to the client; 10. The client sequentially verifies the local proof, the range ownership proof, and the global state proof; 11. If the final global state root is consistent with the block header state root, the query result is accepted.

[0057] The historical status query process is as follows: A historical status query request is represented as: Hist(addr, hl, hu) Where hl represents the lower bound of the query block height, and hu represents the upper bound of the query block height.

[0058] The specific steps are as follows: 1. The system receives a historical status query request Hist(addr, hl, hu); 2. The system queries the routing table based on addr; 3. Locate the range [Li, Ui] containing this address in the routing table; 4. The system determines the target storage instance Instance_i; 5. Construct the composite bond range for the target instance: <addr, hl> arrive<addr, hu> 6. The target instance queries the underlying learning-based authentication storage engine for historical versions of the address within the specified block height range; 7. The target instance returns a set of historical state versions and local proof; 8. Supplementary proof of ownership for the authentication layer; 9. The authentication layer supplements global state proof; 10. The client verifies the historical query results using combinatorial proofs; 11. If the verification passes, it means that the returned historical state version is true and complete, and is committed to by the global state root.

[0059] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A segmented learning-based authentication sharding state storage system for consortium blockchains, characterized in that: It includes a global state root layer (1) for aggregating all committee authentication roots and generating a global state root to be written into the block header; The committee authentication layer (2) is used to aggregate all range descriptors managed by the committee and generate the committee authentication root; The interval description and routing layer (3) are used to maintain the mapping relationship between state addresses, address ranges, storage instances and committees; The interval-based learning-type authentication storage instance layer (4) is used to maintain the status data and historical versions within the corresponding address interval; The underlying learning-based authentication storage engine layer (5) is used to organize state versions according to composite keys and generate local integrity certificates.

2. The interval-based learning-based authentication sharding state storage system for consortium blockchains according to claim 1, characterized in that: The state data in the interval-based learning-based authentication storage instance layer (4) includes the state address and the state value, and the composite key in the underlying learning-based authentication storage engine layer (5) consists of the state address and the block height.

3. The interval-based learning-based authentication sharding state storage system for consortium blockchains according to claim 1, characterized in that: The interval-based learning-type authentication storage instance layer (4) includes a write cache layer for receiving newly written status versions; The ordered state data file layer is used to store state versions sorted according to composite keys; The learned index file layer is used to predict the location of the target state version based on the composite key; The authentication file layer is used to generate local integrity certificates; The local state root generation module is used to generate the local state root for this instance.

4. A segmented learning-based authentication sharding state storage system for consortium blockchains according to claim 3, characterized in that: The interval description and the interval descriptor in the routing layer (3) bind the local state root to the address interval affiliation relationship in the sharding environment. The routing table is used to locate the target address interval, target storage instance and its affiliated committee based on the state address. The data in the routing table undergoes one or more of the following changes: the addition of an address interval, the splitting of an address interval, the merging of adjacent address intervals, the change of the local state root corresponding to the interval, or the change of the interval mapping version.

5. A segmented learning-based authentication sharding state storage system for consortium blockchains according to claim 4, characterized in that: The steps for splitting the address range are as follows: S1. The system checks whether the target instance meets the splitting conditions; S2. The system selects the split boundary based on address distribution, number of states, or access load; S3. The system guarantees that the address boundaries are complete. S4. The system creates a left instance and a right instance; S5. The system assigns the status version in the original instance to the corresponding new instance according to the status address; S6. Rebuild or update the learning index files for both the left and right instances; S7. The left and right instances each generate local authentication files; S8. The left instance and the right instance each generate a new local state root; S9. The system generates two new interval descriptors; S10. System updates routing table; S11. System Update Committee Certification Root; S12. System updates global state root.

6. A segmented learning-based authentication sharding state storage system for consortium blockchains according to claim 5, characterized in that: The steps for merging adjacent address ranges are as follows: S1. The system checks whether two adjacent instances meet the merge conditions; S2. The system confirms that the address ranges of the two instances are continuous and do not overlap; S3. The system creates a new merge instance; S4. The system reads the state versions from the two original instances; S5. The system merges state versions in an orderly manner according to the composite key; S6. The system generates a new ordered state data file; S7. The system generates a new learning index file; S8. The system generates a new authentication file; S9. The system calculates the local state root of the new instance; S10. The system generates a new interval descriptor; S11. The system deletes or discards the original two range descriptors; S12. System updates routing table; S13. System Update Committee Certification Root; S14. System updates global state root.

7. A segmented learning-based authentication sharding state storage system for consortium blockchains according to claim 6, characterized in that: The interval-based learning-type authentication storage instance layer (4) adopts a three-level authentication structure, including local storage authentication, interval ownership authentication and global state authentication.

8. A segmented learning-based authentication sharding state storage system for consortium blockchains according to claim 7, characterized in that: The local storage authentication is used to prove that the query result does indeed belong to a certain interval-based learning-type authentication storage instance. The verification end reconstructs the local state root based on the query result and the local proof. If the reconstructed local state root is equal to the local state root of the interval-based storage instance recorded in the interval descriptor, it means that the query result belongs to the corresponding instance.

9. A segmented learning-based authentication sharding state storage system for consortium blockchains according to claim 7, characterized in that: The interval ownership authentication is used to prove that the target state address does indeed belong to the address interval that the instance is responsible for, and that the instance's local state root is committed by the interval descriptor. The verification end verifies whether the state address is in the interval descriptor, and at the same time verifies whether the interval descriptor is committed by the committee-certified root. If the verification passes, it means that the storage instance is legally responsible for the interval where the target address is located under the current mapping version.

10. A segmented learning-based authentication sharding state storage system for consortium blockchains according to claim 7, characterized in that: The global state authentication is used to prove that the committee authentication root belongs to the global state root. The system aggregates all committee authentication roots to generate a global state root and writes the global state root into the block header or global state commitment. The verification end verifies whether the target committee authentication root is committed by the global state root through global proof. If the final global state root is consistent with the state root in the block header, the query result verification is successful.

Images