Trusted data storage method and system based on hierarchical multi-chain architecture

Abstract

The invention relates to a trusted data storage method and system based on a hierarchical multi-chain architecture, the hierarchical multi-chain architecture comprises an application scene layer, an interface layer, a plurality of service processing chains, a distributed storage layer and an anchor chain, and the trusted data storage method comprises the following steps: the application scene layer obtains to-be-stored data; uploading to a storage service in a distributed storage layer, and obtaining a unique content identifier returned by the distributed storage layer; the interface layer initiates a data anchoring transaction to a corresponding business processing chain based on the to-be-stored data to realize data chain evidence storage; state roots of the multiple service data chains are obtained and submitted to the anchoring chain, and trust anchoring is achieved; and the interface layer responds to the data verification request, carries out integrity verification through the distributed storage layer, carries out existence verification through the corresponding service data link, carries out global state root verification through the anchor chain, and returns a data verification result. Compared with the prior art, the method has the advantages of realizing cross-domain mutual trust, optimizing a trust anchoring mechanism and the like.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchains, and in particular to a trusted data storage method and system based on a hierarchical multi-chain architecture. BACKGROUND

[0002] With data becoming a key production factor, building a basic trust facility to support the trusted flow and collaboration of data has become the core demand for the development of digital economy. However, when building a trusted data space across organizations and fields, the existing technical solutions have fundamental defects. Traditional centralized data management systems have single point of failure, internal tampering risk and data island problem, and their trust model relies on the endorsement of a single institution, which is difficult to meet the trusted needs in multi-party collaboration scenarios.

[0003] Blockchain technology provides a new paradigm for building decentralized trust with its distributed consensus and tamper-proof characteristics. The industry generally adopts a hybrid mode of storing hashes on the chain and storing original files off the chain. Among them, distributed storage systems are often used as off-chain storage solutions due to their cost advantages. However, the existing single blockchain + distributed storage solution is only a simple superposition of technology and does not form a complete and trusted data base, with the following core defects: (1) Lack of data availability guarantee: existing solutions only chain the content identifier (CID) returned by the distributed storage, but CID itself cannot guarantee the long-term availability of the data it points to. Random exit of storage nodes can lead to data loss, making the on-chain credentials become null pointers and breaking the entire trust chain.

[0004] (2) Weak dynamic data management capabilities: when data needs to be updated or its status changes, existing solutions lack effective on-chain mechanisms to manage the association between versions, cannot form a coherent and verifiable data evolution history, and are difficult to support dynamic business scenarios.

[0005] (3) System architecture rigidity and lack of isolation: different business domains have different requirements for performance, privacy and compliance. Hashing all data on a single chain can lead to resource competition, performance interference, and inability to achieve necessary business isolation and policy customization.

[0006] (4) Difficulty in cross-domain interoperability and verification: in the context of multiple chains coexisting, data often needs to be verified by applications on different blockchains. Existing solutions are limited to closed single-chain environments and lack standardized and trusted mechanisms to prove the authenticity and integrity of their data to external systems, forming a new data verification island.

[0007] In summary, the prior art lacks a systematic solution that can meet the needs of massive data processing, cross-domain business isolation, dynamic life cycle management and open interoperability while ensuring data credibility, thus failing to perform the core role of a social-level credible data infrastructure. SUMMARY

[0008] The present application aims to overcome the defects of the prior art and provide a layered multi-chain architecture-based credible data storage method and system to solve or partially solve the problems of data availability guarantee and weak dynamic data management capability in existing methods.

[0009] The object of the present application can be achieved by the following technical solutions: In one aspect of the present application, a layered multi-chain architecture-based credible data storage method is provided, which includes an application scenario layer, an interface layer, a plurality of business processing chains, a distributed storage layer and an anchor chain. The method comprises the following steps: The application scenario layer obtains the data to be stored, uploads it to the storage service in the distributed storage layer, and obtains the unique content identifier returned by the distributed storage layer; The interface layer initiates a data anchoring transaction to the corresponding business processing chain based on the data to be stored, and realizes data chain notarization; The state root of the plurality of business data chains is obtained and submitted to the anchor chain, realizing trust anchoring; The interface layer responds to the data verification request, performs integrity verification through the distributed storage layer, existence verification through the corresponding business data chain, and global state root verification through the anchor chain, and returns the data verification result.

[0010] As a preferred technical solution, the method further comprises the following steps: In response to a notarized data update request, the new data is uploaded to the storage service in the distributed storage layer, and the new unique content identifier returned by the distributed storage layer is obtained; An update transaction is initiated to the corresponding business processing chain, and the original unique content identifier and the new unique content identifier are associated through a contract to form a traceable version chain; The state root of the updated business data chain is anchored to the core anchor chain.

[0011] As a preferred technical solution, the process of obtaining the unique content identifier comprises the following steps: The application scenario layer uploads the data to be stored through the data anchoring software in the interface layer; The data anchoring software uploads the data to be stored to the optimal storage service in the distributed storage layer according to a predetermined strategy; The storage service returns a unique content identifier of data, and the data anchoring software calculates a cryptographic hash value of the data to be stored.

[0012] As a preferred technical solution, the data anchoring transaction includes a unique content identifier corresponding to the data to be stored, a hash value of the data to be stored, and a timestamp.

[0013] As a preferred technical solution, the trust anchoring process includes the following steps: Periodically polling a plurality of business processing chains to obtain the latest state root; Submitting the state root of each business processing chain to the state consensus contract of the anchoring chain for storage, and anchoring the local state of each business processing chain to the global trust root.

[0014] As a preferred technical solution, the data verification request includes a unique content identifier or a transaction identifier of the data.

[0015] Another aspect of the present application provides a trusted data storage system based on a hierarchical multi-chain architecture, for implementing the trusted data storage party described above, the system comprising: An anchoring chain including a blockchain main chain network, a state consensus contract, a global verification contract, and an arbitration governance contract; A distributed storage module including an IPFS cluster, a Filecoin network, and a private storage; A vertical field data chain including a plurality of business processing chain networks, a notarization contract, a verification contract, and a cross-chain contract; A unified service interface module including a data anchoring software and a unified verification gateway; An application ecosystem module including a plurality of vertical industry applications.

[0016] As a preferred technical solution, in the anchoring chain, The state consensus contract is configured to periodically poll a plurality of business processing chains, store the state root of each business processing chain, and anchor the local state of each business processing chain to the global trust root; The global verification contract is configured to perform global state root verification and return a data verification result; The arbitration governance contract is configured to provide arbitration logic based on preset rules and multi-party consensus when a cross-domain dispute occurs.

[0017] As a preferred technical solution, in the distributed storage module, The IPFS cluster is configured to store frequently accessed hot data; The Filecoin network is configured to store cold data that needs to be stored for a long time; The private storage is configured to store highly sensitive data.

[0018] As a preferred technical solution, in the unified service interface module, The data anchoring software is used to provide a multi-language SDK, which encapsulates the interaction logic of blockchain and distributed storage modules; The unified verification gateway is used to provide an API interface to respond to data verification requests and return data verification results.

[0019] Compared with the prior art, the present invention has at least one of the following beneficial effects: (1) Achieving cross-domain mutual trust: This invention adopts a layered multi-chain architecture that combines a core anchor chain with vertical domain data chains (business domains). High-concurrency data services are distributed across multiple domain chains (business processing chains) for parallel processing, breaking through the performance bottleneck of a single chain and enabling the infrastructure to support the throughput of social-scale data. Different domains can customize strategies on their dedicated chains to achieve effective isolation of resources, privacy, and compliance requirements. At the same time, cross-domain mutual trust is achieved through the core anchor chain, laying the architectural foundation for a large-scale trusted data space.

[0020] (2) Optimized Trust Anchoring Mechanism: This invention designs a state root aggregation anchoring mechanism, which periodically and in batches converges the local trust of data chains in various vertical domains to the core anchoring chain. While maintaining high performance and low cost, each domain chain inherits the strong security of the core anchoring chain, realizing a qualitative change from local trust to global trust. The core anchoring chain becomes the trust root of the entire digital ecosystem, simplifying the complexity of cross-domain and cross-system data verification, and providing core support for building an interconnected trust network.

[0021] (3) Optimize storage reliability: This invention deeply integrates the active verification mechanism into the distributed storage layer, ensuring the long-term availability and integrity of off-chain data through continuous challenges, ensuring that on-chain credentials (CID) are not null pointers, and truly incorporating massive amounts of off-chain data into the trusted system, thus solving the core trust bottleneck of data elementization. The hybrid storage strategy can dynamically select the optimal solution according to the data characteristics, ensuring trustworthiness while making the infrastructure have excellent economy and sustainability. Attached Figure Description

[0022] Figure 1 This is a flowchart of a trusted data storage method based on a hierarchical multi-chain architecture, as shown in the embodiment. Figure 2 This is a flowchart of the data preprocessing and trusted storage process in the embodiment; Figure 3 This is a flowchart illustrating the domain data chain evidence storage process in this embodiment. Figure 4 This is a flowchart illustrating the global state consensus and trust anchoring process in the embodiment. Figure 5This is a flowchart illustrating global data verification and cross-chain mutual recognition in the embodiment; Figure 6 This is a flowchart illustrating the data lifecycle and version management in the embodiment; Figure 7 This is a schematic diagram of a trusted data storage system based on a hierarchical multi-chain architecture, as shown in the embodiment. Detailed Implementation

[0023] 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, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0024] Example 1 To address the aforementioned problems with existing technologies, this embodiment provides a trusted data storage system based on a layered multi-chain architecture. It aims to overcome the core pain point of unreliable long-term availability and trustworthiness of off-chain distributed storage data, ensuring that on-chain credentials always correspond to searchable, tamper-proof original data. This system overcomes the performance and capacity bottlenecks of a single blockchain, achieving efficient horizontal scaling of infrastructure and secure isolation across multiple business domains. It also constructs standardized cross-chain / cross-domain trusted verification channels, resolving interoperability and trusted mutual recognition issues in complex multi-chain ecosystems. Furthermore, it provides a flexible data governance architecture that adaptively balances data privacy, storage costs, regulatory auditing, and business needs.

[0025] See Figure 7 The system architecture of this embodiment includes: 1. Core anchor chain (Layer 1).

[0026] Serving as the root of trust for the entire trusted data space, it is supported by a high-performance consortium blockchain. Its main core components are as follows: (1) State Consensus Contract. It does not process specific business data, but periodically accepts state roots submitted by data chains from various vertical fields. This state root is the aggregate fingerprint of all data operations of each data chain within a specific period. Any slight tampering will cause it to change, thereby achieving a strong binding between the overall data state and the trust of the main chain.

[0027] (2) Global Verification Contract. Responsible for handling cross-chain verification requests from external sources, providing the entire ecosystem with a unified data authenticity verification service based on the core anchor chain's trust endorsement.

[0028] (3) Arbitration governance contract. In the event of cross-regional disputes, provide an arbitration logic based on pre-set rules and multi-party consensus to ensure the orderly operation of infrastructure.

[0029] 2. Distributed storage layer.

[0030] As a massive data persistence layer serving as infrastructure, it provides low-cost, highly reliable data storage services. It employs an intelligent hybrid storage model, dynamically selecting the optimal storage backend based on the data's value, sensitivity, and access patterns. This primarily includes: (1) IPFS cluster. As a high-performance caching layer, it serves frequently accessed hot data.

[0031] (2) Filecoin Network. As a persistent storage layer, it serves cold data that needs to be stored for a long time, and ensures storage reliability through a cryptographic economic model.

[0032] (3) Private storage. Serves highly sensitive data, supports private deployments with strict compliance requirements, and can selectively participate in global data verification.

[0033] 3. Vertical domain data chain (Layer 2).

[0034] It serves as a horizontal expansion of infrastructure and a business support layer. It comprises a cluster of multiple domain-specific chains, such as judicial evidence storage chains, digital copyright chains, and supply chain data chains. Each chain can customize its consensus, data structure, and privacy policies according to its domain characteristics, forming an autonomous data trust domain capable of handling high-concurrency data transactions.

[0035] 4. Unified service interface layer.

[0036] It provides standardized and easy-to-use data trust services for upper-layer applications, greatly reducing the technical integration threshold. This mainly includes: (1) Data Anchoring SDK. A multi-language SDK is provided, which encapsulates all the complex logic for interacting with blockchain and distributed storage. Developers can achieve trusted on-chain data uploading and anchoring through a simple API.

[0037] (2) Unified verification gateway. Provides a standardized RESTful API interface for internal and external systems (including other blockchains) to query and verify any data anchored on the infrastructure, enabling seamless and trusted interoperability across systems.

[0038] 5. Apply ecological layer.

[0039] Various vertical applications can be built upon this infrastructure. Ecosystem participants can rapidly develop and deploy trusted applications serving scenarios such as finance, government affairs, shipping and trade, and the Internet of Things, based on the core anchor chain, vertical domain data chains, and a unified service interface layer, thus building a thriving trusted data ecosystem.

[0040] Example 2 Building upon Example 1, this example provides a trusted data storage method based on a hierarchical multi-chain architecture. The trusted data storage system implementation based on Example 1 is described in [reference needed]. Figure 1 The method includes the following steps: Step S1: Data preprocessing and trusted storage.

[0041] This process features policy-driven intelligent storage, pre-positioned integrity credentials, and transparent infrastructure complexity. It dynamically selects storage backends based on data characteristics, achieving optimal configuration of cost, performance, and privacy. Dual credentials (hash and CID) are generated at the data entry point, laying the foundation for building an end-to-end trust chain. All underlying technical details are encapsulated through an SDK, providing applications with easy-to-use trusted data services.

[0042] See Figure 2 This process includes steps S101-S103: Step S101: The application ecosystem layer initiates a request through the data anchoring SDK to upload the original data file.

[0043] Step S102: The SDK uploads the original data file to the optimal storage service in the distributed storage layer according to the preset intelligent strategy.

[0044] Step S103: The storage service returns a unique content identifier (CID) for the data, and the SDK synchronously calculates the cryptographic hash value of the data, forming a double guarantee of data integrity.

[0045] Step S2: Domain data chain notarization.

[0046] This process features architecture-level business isolation and scalability, lightweight on-chain metadata, and domain-specific autonomy and trusted records. It achieves resource isolation and horizontal performance scaling through domain-specific blockchains, supporting diverse data services. By only uploading key fingerprint information to the blockchain, it significantly reduces the blockchain load and improves overall system performance. It establishes immutable and trusted records within each autonomous domain, meeting domain-specific auditing and governance requirements.

[0047] See Figure 3 This process includes steps S201-S202: Step S201: Based on the domain of the data, the SDK selects the corresponding vertical domain data chain and initiates a data anchoring transaction. The transaction includes core metadata such as CID, data hash, and timestamp.

[0048] Step S202: The evidence storage contract on the target data chain receives and processes the transaction and records it on the chain.

[0049] Step S3: Global state consensus and trust anchoring.

[0050] This step features trust convergence, efficient global consensus, and a unified trust anchor. It unifies and aggregates dispersed intra-domain trusts to a higher-security global trust root, thereby enhancing trust. By batch aggregating state roots, it achieves consensus on the entire domain's data state at extremely low on-chain cost. This provides the technical means for the core anchor chain to become the sole source of trust across domains and cross-chain ecosystems.

[0051] See Figure 4 This process includes steps S301-S303: Step S301: The system periodically polls the data chains of each vertical domain to obtain their latest Merkle root status.

[0052] Step S302: Submit the state roots of each chain in batches to the state consensus contract of the core anchor chain for storage.

[0053] Step S303: At this point, the local states of the data chains in each domain are safely converged and anchored to the global root of trust, completing the trust upgrade.

[0054] Step S4: Full-domain data verification and cross-chain mutual recognition.

[0055] This process features end-to-end verification, ecosystem-level interoperability, and proactive reliability proof. It covers three levels: off-chain data, on-chain records of global state, forming a robust verification loop. Through standardized gateways and contracts, it provides one-click verification services to external systems, breaking down trust barriers. The verification process itself is a continuous challenge to data retrievability, ensuring the long-term validity of the evidence chain.

[0056] See Figure 5 This process includes steps S401-S403: Step S401: When data verification is required, the verification direction initiates a request to the unified verification gateway, providing the data's CID or transaction identifier.

[0057] Step S402: Verify the gateway to perform end-to-end full-link verification: (1) Retrieve data from the distributed storage layer and verify its integrity (hash matching).

[0058] (2) Request the Merkle existence proof of the data record from the source data chain.

[0059] (3) Call the global verification contract of the core anchor chain to verify that the existence proof corresponds to a confirmed global state root.

[0060] Step S403: Only if all three verification steps (1), (2), and (3) above are passed will the cross-chain verification gateway return a "verification successful" result to the verifier; otherwise, it will return a "verification failed" result.

[0061] Furthermore, this method can also introduce zero-knowledge proofs (ZKP) to achieve data usability without visibility. Specifically, zero-knowledge proof technology is introduced into the notarization and verification stages. The notarization party can generate a zero-knowledge proof proving that it owns a certain file and that its hash has been correctly notarized, without exposing any file content or metadata on the blockchain. The verifier only needs to verify the proof to confirm the authenticity of the notarization. This will greatly enhance data privacy protection, meet the notarization needs of sensitive data such as trade secrets and personal privacy, without sacrificing verifiability. This can extend the system's application scenarios to fields with high compliance requirements, such as finance and healthcare.

[0062] Furthermore, this method can also incorporate blockchain oracle technology and artificial intelligence technology to introduce trusted data from the external world and realize greater business value. Specifically, decentralized oracles can be used to introduce authoritative external data sources (such as weather information, medical data, IoT sensor data, etc.) into the system as auxiliary verification or triggering conditions for evidence storage data. Further, decentralized artificial intelligence can be combined to automate the analysis, classification, or anomaly detection of the evidence storage data. This enriches the dimensions and value of the evidence storage data, enabling condition-triggered intelligent storage and evidence storage, such as automatic evidence storage when IoT data reaches a certain threshold, or automatic identification and preservation of infringing content by artificial intelligence.

[0063] Step S5: Data lifecycle and version management.

[0064] This process features auditable version evolution, support for complex business processes, and good historical compatibility. It records the entire process of dynamic data changes on an immutable ledger, meeting compliance and auditing requirements. It extends the capabilities of infrastructure from static evidence storage to dynamic business processes, expanding application boundaries. All historical versions are fully preserved and can be independently verified, ensuring the integrity and trustworthiness of the data lifecycle.

[0065] See Figure 6 When the evidence storage data needs to be updated, execute steps S501-S503: Step S501: Upload and store the new version data to obtain the new CID.

[0066] Step S502: Initiate an update transaction on the source data chain, and associate the old and new CIDs through a contract to form a traceable version chain.

[0067] Step S503: The state changes caused by this version update are ultimately anchored to the core anchor chain through step S3, ensuring the integrity and continuity of the entire data history.

[0068] Furthermore, this method can also expose the system's core capabilities (such as evidence preservation, verification, storage, and cross-chain functionality) through APIs / SDKs, allowing third-party developers to build vertical applications on top of them and establish an application marketplace for trading standardized evidence preservation solutions or data services incubated by the system. This attracts more developers, rapidly enriches the application ecosystem, and creates network effects and a competitive advantage.

[0069] The implementation process of this method will be described below with a specific example.

[0070] 1. System initialization and core parameter configuration.

[0071] (1) When implementing this system, the basic environment must first be set up and the key parameters configured: Establish the core anchor chain. A consortium blockchain architecture is adopted, built on the Chang'an Chain ChainMaker V2.3.0 framework.

[0072] Four consensus nodes are initially set up, each deployed and maintained by a different trusted institution (such as regulatory authorities, large state-owned enterprises, judicial appraisal centers, etc.).

[0073] The efficient Tendermint Byzantine Fault Tolerant (TBFT) consensus mechanism is used, with a block time set to 1 second.

[0074] A state consensus contract, a global verification contract, and an arbitration governance contract are deployed on the core anchor chain. The periodic parameter for state root submission is set to execute a batch anchoring once every 100 blocks.

[0075] (2) Deploy and configure the data chain cluster for the vertical domain.

[0076] Build a data chain for vertical industries. Adopt a consortium blockchain architecture and build it based on the Chang'an Chain ChainMaker V2.3.0 framework.

[0077] Initially, three vertical data chains were deployed to serve judicial evidence preservation, digital copyright, and supply chain traceability scenarios, respectively.

[0078] Each vertical domain data chain initially sets up at least 4 consensus nodes, which are deployed and maintained by trusted institutions in different vertical domains (for example, in judicial evidence preservation, these could be internet courts, notary offices, third-party auditing companies, etc.).

[0079] The efficient Tendermint Byzantine Fault Tolerant (TBFT) consensus mechanism is used, with a block time set to 2 seconds.

[0080] Specifically, evidence management contracts, verification contracts, cross-chain contracts, etc., optimized for their respective business scenarios are deployed on the data chains of each vertical industry.

[0081] (3) Deploy and configure distributed storage.

[0082] Deploy a private IPFS cluster consisting of at least 5 nodes as a hot data caching layer.

[0083] In accordance with the requirements of the Filecoin mainnet, we need to prepare storage media capable of persistently storing cold data and deploy Filecoin access services.

[0084] Deploy a private deployment storage service that is compatible with mainstream private storage protocols (such as Amazon S3) for storing highly sensitive data.

[0085] Configure storage policy parameters and preset policy rules in the evidence storage SDK. For example: files smaller than 10MB that are frequently accessed should be stored in the IPFS cluster; files larger than 10MB that need to be stored for a long time should be stored in the IPFS cluster network; and commercial contracts involving personal privacy should be stored in private storage.

[0086] (4) Deploy and configure the unified service interface layer.

[0087] The deployment data anchoring SDK supports Java, Go, and Python languages. The SDK has the aforementioned storage strategies built-in and integrates the national cryptographic SM2 / SM3 algorithms for signature and hash calculation, etc.

[0088] Deploy a unified verification gateway that supports horizontally scalable RESTful services and provides standard HTTP APIs (e.g., POST / api / v1 / evidence / verify).

[0089] The implementation steps include: (1) Data preprocessing and trusted storage (corresponding to) Figure 2 ).

[0090] Users can upload a 50MB on-site surveillance video (i.e., the original data file) through the judicial evidence preservation application in the application ecosystem.

[0091] The judicial evidence preservation application calls the corresponding method of the data anchoring SDK.

[0092] The SDK automatically selects to upload files to the Filecoin network (distributed storage layer) based on a preset strategy (files 50MB > 10MB need to be stored for a long time).

[0093] After the file is successfully uploaded, the SDK obtains the returned CID and simultaneously uses the SM3 algorithm to calculate the file's hash value.

[0094] This step employs an intelligent storage strategy and pre-verification of integrity, achieving a balance between cost and performance, and preparing reliable target data for subsequent verification.

[0095] (2) Domain data chain evidence storage (corresponding to) Figure 3 ).

[0096] Based on the business type of this judicial evidence preservation, the SDK automatically selects the judicial evidence preservation chain as the vertical domain data chain.

[0097] The SDK constructs a notarization transaction, the transaction content of which includes: CID, SM3 hash, timestamp, digital identity DID for judicial notarization applications, etc.

[0098] The transaction is sent to the judicial evidence storage chain, where it is received and processed by the evidence management contract. After verifying the signature, the contract records the evidence information on the chain and updates the Merkle state tree of the chain.

[0099] This step achieves business isolation and simplified on-chain metadata, minimizing the cost of storing high-definition videos and creating a trusted record within the data chain of this vertical domain.

[0100] (3) Global state consensus and trust anchoring (corresponding to) Figure 4 ).

[0101] The unified verification gateway service polls for its latest Merkle root state approximately every 5 minutes (or when the judicial evidence storage chain generates 100 new blocks).

[0102] The gateway obtains the state root, packages it, and calls the corresponding method of the state consensus contract on the core anchor chain to submit it in batches.

[0103] Specifically, the consensus nodes of the core anchor chain confirm this submission. At this point, all evidence-preserving states of the judicial evidence-preserving chain prior to this moment are securely anchored to the main chain.

[0104] This step achieves trust upgrade and efficient anchoring, thereby improving the security of the business chain at extremely low on-chain costs.

[0105] (4) Global data verification and cross-chain mutual recognition (corresponding to) Figure 5 ).

[0106] A commercial entity (such as an insurance company), acting as an external verifier, needs to verify the authenticity of the video. It sends a verification request to the unified verification gateway, providing the stored CID.

[0107] Verify that the gateway performs a three-step verification: a. Data integrity verification: The gateway successfully retrieved the video file from the IPFS cluster network based on the CID, recalculated its SM3 hash, and compared it with the hash recorded on the judicial evidence storage chain. The result was consistent.

[0108] b. Existence verification: The gateway requests the Merkle proof of the evidence storage transaction from the judicial evidence storage chain.

[0109] c. Global Consistency Verification: The gateway calls the global verification contract on the core anchor chain, inputs the Merkle proof and state root obtained in step b, and the contract verifies that this state root has indeed been recorded by the proof root contract and is valid.

[0110] Once all three verification steps are passed, the gateway returns confirmation of the authenticity and validity of the result to the business entity.

[0111] This step enables end-to-end full-chain verification and seamless cross-chain interoperability, providing authoritative and convenient verification services for external systems.

[0112] (5) Data lifecycle and version management (corresponding to) Figure 6 ).

[0113] An additional "Expert Opinion Report" needs to be issued for this video evidence.

[0114] Users upload the "Expert Opinion Report" PDF file through the judicial evidence preservation application. The system executes step S1 to obtain the CID_new of the new file.

[0115] An update transaction is initiated on the judicial evidence storage chain. This transaction associates the CID of the original video with the CID_new of the "Appraisal Report" through the evidence storage management contract, and records the update reason as "addition of appraisal materials".

[0116] This update transaction will also trigger step S3, which will eventually anchor the new chain state to the core anchor chain, thus forming a complete and tamper-proof chain of evidence from the original video to the supplementary materials.

[0117] This step enables traceable version evolution, perfectly supporting the trusted management of dynamic evidence chains.

[0118] This method has the following beneficial effects: 1. Interoperability Optimization: From Closed Systems to Verifiable Services in an Open Ecosystem. This invention innovatively designs a standardized unified verification gateway and on-chain global verification contract, providing a unified "verification" entry point for the entire digital ecosystem. It offers one-click data verification services to any external system (including other blockchains), completely breaking down data silos and promoting the efficient flow and aggregation of data elements. Verifying parties do not need to understand the complex underlying architecture to obtain verification results with global trust endorsement, greatly reducing the technical threshold and trust costs of data collaboration.

[0119] 2. Data Model Optimization: From Static Snapshots to Dynamic Lifecycle Trusted Management. This invention innovatively designs a traceable data version management mechanism natively on the blockchain, fully recording the evolution history of data. This enables the infrastructure not only to manage static data but also to meet the trusted management needs of continuously changing data states in complex business scenarios such as supply chains and digital assets. All version relationships are recorded immutably, forming a complete trusted evolution chain, providing strong technical support for compliance audits and dispute resolution.

[0120] 3. Ease of use optimization: Unified interface encapsulation from complex integration to easy access. This invention encapsulates the complexity of the underlying technology through a unified data service SDK. Application developers do not need blockchain expertise to inject trusted capabilities into their applications, just like calling a public service, which is conducive to the rapid popularization of the technology and the prosperity of the ecosystem. The SDK incorporates best practices to ensure the standardization and correctness of the entire process of data generation, storage and verification, improving the overall robustness and reliability of the infrastructure.

[0121] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A trusted data storage method based on a hierarchical multi-chain architecture, characterized in that, The layered multi-chain architecture includes an application scenario layer, an interface layer, multiple business processing chains, a distributed storage layer, and an anchor chain. The trusted data storage method includes the following steps: The application scenario layer obtains the data to be stored, uploads it to the storage service in the distributed storage layer, and obtains the unique content identifier returned by the distributed storage layer. Based on the data to be stored, the interface layer initiates a data anchoring transaction to the corresponding business processing chain to realize data chain notarization. Obtain the state roots of multiple business data chains and submit them to the anchor chain to achieve trust anchoring; The interface layer responds to the data verification request by performing integrity verification through the distributed storage layer, existence verification through the corresponding business data connection, and global state root verification through the anchor chain, and returns the data verification result.

2. The trusted data storage method based on a hierarchical multi-chain architecture according to claim 1, characterized in that, It also includes the following steps: In response to the data update request, the new data is uploaded to the storage service in the distributed storage layer, and a new unique content identifier is returned by the distributed storage layer. Initiate an update transaction to the corresponding business processing chain, and associate the original unique content identifier with the new unique content identifier through a contract to form a traceable version chain; Anchor the state root of the updated business data chain to the core anchor chain.

3. The trusted data storage method based on a hierarchical multi-chain architecture according to claim 1, characterized in that, The process of obtaining the unique content identifier includes the following steps: The application scenario layer uploads the data to be stored through the data anchoring software in the interface layer; The data anchoring software uploads the data to be stored to the optimal storage service in the distributed storage layer according to a preset strategy. The storage service returns a unique content identifier for the data, and the data anchoring software synchronously calculates the cryptographic hash value of the data to be stored.

4. The trusted data storage method based on a hierarchical multi-chain architecture according to claim 1, characterized in that, The data anchoring transaction includes a unique content identifier corresponding to the data to be stored, a hash value containing the stored data, and a timestamp.

5. A trusted data storage method based on a hierarchical multi-chain architecture according to claim 1, characterized in that, The trust anchoring process includes the following steps: Periodically poll multiple business processing chains to obtain the latest state root; The state roots of each business processing chain are submitted to the state consensus contract of the anchor chain for storage, and the local state of each business processing chain is anchored to the global trust root.

6. A trusted data storage method based on a hierarchical multi-chain architecture according to claim 1, characterized in that, The data verification request includes a unique content identifier or transaction identifier for the data.

7. A trusted data storage system based on a hierarchical multi-chain architecture, characterized in that, For implementing a trusted data storage provider as described in any one of claims 1-6, the system comprises: Anchored chains include the main blockchain network, state consensus contract, global verification contract, and arbitration governance contract; Distributed storage modules, including IPFS clusters, Filecoin network, and private storage; Vertical domain data chains include multiple business processing chain networks, evidence storage contracts, verification contracts, and cross-chain contracts; The unified service interface module includes data anchoring software and a unified verification gateway; The application ecosystem module includes multiple vertical industry applications.

8. A trusted data storage system based on a hierarchical multi-chain architecture according to claim 7, characterized in that, In the anchoring chain The state consensus contract is used to periodically poll multiple business processing chains, store the state root of each business processing chain, and anchor the local state of each business processing chain to the global trust root. The global verification contract is used to perform global state root verification and return the data verification result. The arbitration governance contract is used to provide arbitration logic based on preset rules and multi-party consensus in the event of cross-domain disputes.

9. A trusted data storage system based on a hierarchical multi-chain architecture according to claim 7, characterized in that, In the distributed storage module The IPFS cluster is used to store frequently accessed hot data; The Filecoin network is used to store cold data that needs to be preserved for a long time; The private storage is used to store highly sensitive data.

10. A trusted data storage system based on a hierarchical multi-chain architecture according to claim 7, characterized in that, In the unified service interface module The data anchoring software is used to provide a multi-language SDK, which encapsulates the interaction logic of blockchain and distributed storage modules; The unified verification gateway is used to provide an API interface to respond to data verification requests and return data verification results.

Images