Blockchain-based method for trusted storage and sharing of app data

Abstract

This application relates to the field of blockchain technology and application security, and discloses a blockchain-based method for trusted storage and sharing of APP data. This method maintains a verifiable state container off-chain, containing state data and access policies in a dual Merkle tree, and records its root hash on the blockchain. For different updates, corresponding proofs are generated: a single-step proof containing a Merkle proof is generated for single-step updates; a composite proof containing zero-knowledge proofs is generated for complex processes. The smart contract only needs to verify the proof to atomically update the root hash. During data sharing, data and dual Merkle proofs are provided for consumers to verify the authenticity of the data and the legality of access. This invention places complex computation off-chain, achieving low-cost and constant-overhead on-chain verification. Simultaneously, through the dual-tree, dual-proof mechanism, it provides highly secure trusted data storage and fine-grained access control capabilities.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology and application security, specifically a blockchain-based method for trusted storage and sharing of APP data. Background Technology

[0002] With the widespread adoption of mobile internet, applications (APPs) have become central to digital life, generating and processing massive amounts of user and business data during their operation. Traditionally, this data has been stored on centralized servers controlled by application operators. While this architecture is mature, its inherent opacity makes the data appear as if it's stored in a "black box." Users and third-party auditing institutions find it difficult to independently and effectively verify the authenticity, integrity, and compliance of the data's operational history, leading to increasingly prominent issues of data silos and trust deficits.

[0003] To address the aforementioned trust issues, blockchain technology, with its decentralized, immutable, and traceable characteristics, has been introduced as the underlying infrastructure for building trusted data systems. However, solutions that place all application data and business logic entirely on the blockchain face serious challenges such as high transaction costs, low processing performance, and lack of privacy protection, which significantly limits its practical deployment in complex, high-frequency application scenarios.

[0004] To address this, the industry has further explored technical solutions for on-chain and off-chain collaboration. These typically store large-scale data off-chain, anchoring only the cryptographic commitments (such as hash values) of the data to the blockchain. While this approach improves efficiency and reduces costs to some extent, existing solutions still have deep-seated limitations. These solutions often only prove data integrity at a specific point in time, failing to provide effective proof of legitimacy for complex state transition processes. In other words, they cannot cryptographically ensure that the evolution from an old state to a new state strictly adheres to pre-defined business rules. Especially when a business process involves multiple dependent steps, existing technologies lack a mechanism to atomically confirm the entire process's execution result on-chain, making it prone to state inconsistencies due to off-chain execution interruptions. Furthermore, in the data sharing phase, there is a lack of an effective means for data recipients to independently verify whether the data access behavior itself is legally authorized.

[0005] Therefore, this invention proposes a blockchain-based method for trusted storage and sharing of APP data to address the shortcomings of existing technologies. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides a blockchain-based method for trusted storage and sharing of APP data. This method solves the problems of existing technologies, such as difficulty in performing low-cost, atomic verification of the execution results of complex business processes and lack of access permission verifiability during data sharing.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a blockchain-based method for trusted storage and sharing of APP data, comprising the following steps:

[0008] Initialize a verifiable state container, which includes a Merkle tree of state data and a Merkle tree of access policies;

[0009] An initial verifiable state container root hash is calculated, and the calculated initial verifiable state container root hash is recorded together with the staking information in the smart contract of the blockchain network.

[0010] In response to a state update request, a state transition proof is generated based on the type of update, and the generated state transition proof is submitted to the smart contract for verification.

[0011] The state transition proof includes a single-step state transition proof for proving a single-step atomic update, or a composite state transition proof for proving a multi-step complex process update.

[0012] Once the smart contract verifies the state transition proof, the root hash of the verifiable state container recorded in the smart contract is updated to the new root hash specified in the generated state transition proof.

[0013] Preferably, the step of calculating an initial verifiable state container root hash includes: obtaining the root hash of the state data Merkle tree and the root hash of the access policy Merkle tree respectively; combining the root hash of the state data Merkle tree, the root hash of the access policy Merkle tree, and a version number, and performing a hash calculation on the combination result to obtain the initial verifiable state container root hash.

[0014] Preferably, the steps for generating a single-step state transition proof include: searching for an authorization policy rule in the access policy Merkle tree that can authorize the current single-step atomic update, and generating a Merkle proof for the found authorization policy rule; performing an update operation on the state data Merkle tree to generate a new root hash of the state data Merkle tree; calculating a new root hash based on the newly generated root hash of the state data Merkle tree; and assembling the old verifiable state container root hash, the calculated new root hash, and the proof payload containing the authorization policy rule and the Merkle proof of the authorization policy rule into a single-step state transition proof.

[0015] Preferably, the steps for generating a composite state transition proof include: updating and modeling a multi-step complex process as a directed acyclic graph, and performing a simulation calculation in an off-chain environment based on the established directed acyclic graph to generate a witness to the execution trajectory; using a pre-built zero-knowledge proof circuit, taking the generated witness as a private input and the starting root hash and the final root hash of the process as public inputs to generate a zero-knowledge proof; and assembling the starting root hash, the final root hash, and the generated zero-knowledge proof into a composite state transition proof.

[0016] Preferably, the steps for verifying a single-step state transition proof in a smart contract include: performing a pre-state consistency verification to confirm that the root hash of the old verifiable state container in the submitted single-step state transition proof is consistent with the root hash of the current record in the smart contract; extracting the authorization policy rule and the Merkle proof of the authorization policy rule from the proof payload, and calling a Merkle proof verification function to verify that the authorization policy rule is a valid member of the access policy Merkle tree.

[0017] Preferably, the steps for verifying a composite state transition proof in a smart contract include: performing a preliminary state consistency verification to confirm that the starting root hash in the submitted composite state transition proof is consistent with the root hash of the current record in the smart contract; and calling a pre-defined zero-knowledge proof verification function to verify that the multi-step complex process update is correctly executed off-chain using the zero-knowledge proof in the submitted composite state transition proof and the common input.

[0018] Preferably, the method further includes: responding to a data request from a data consumer by providing a target data value, a first Merkel proof for proving the authenticity of the data, and a second Merkel proof for proving the legitimacy of access, so that the data consumer can perform local independent verification using the root hash of the authoritative verifiable state container obtained from the smart contract.

[0019] Preferably, the local independent verification includes a double verification, which includes: performing a first verification by using a first Merkle proof to verify that the target data value is a valid component of the state data Merkle tree; performing a second verification by using a second Merkle proof to verify that a policy rule for authorized data sharing is a valid component of the access policy Merkle tree; and accepting the target data value only if both the first and second verifications pass.

[0020] Preferably, the method further includes executing an active commitment protocol, which includes: the smart contract periodically initiating a random challenge containing a randomly generated data key; the holder of the verifiable state container submitting a data value corresponding to the randomly generated data key and a Merkle proof of the data value as a response within a specified time; if the holder of the verifiable state container fails to submit a valid response within the specified time, the smart contract performs a forfeiture operation on the recorded staking information.

[0021] Preferably, the step of submitting the state transition proof to the smart contract for verification, as a batch processing mechanism, includes: accumulating multiple consecutive single-step state transition proofs locally, each of which has an old verifiable state container root hash equal to the new root hash of the previous one, to form a proof sequence; submitting the generated proof sequence to the smart contract through a single blockchain transaction; having the smart contract verify each single-step state transition proof in the proof sequence, and after all verifications pass, directly updating the verifiable state container root hash recorded in the smart contract from the old root hash of the first proof in the sequence to the new root hash of the last proof in the sequence.

[0022] This invention provides a blockchain-based method for trusted storage and sharing of app data. It offers the following advantages:

[0023] This invention achieves significant optimization of system operating costs and high scalability. By distinguishing the types of state updates, this invention designs a "single-step state transition proof" based on Merkle proof for simple single-step atomic updates, and a "composite state transition proof" based on zero-knowledge proof for complex multi-step process updates. This dual-proof mechanism allows high-frequency, simple operations to be verified on-chain in a low-cost manner, while computationally intensive complex business logic is moved to off-chain execution. The final result only needs to be atomically confirmed on-chain through a single zero-knowledge proof verification with fixed cost. This design avoids the high transaction costs associated with directly executing complex business logic on-chain, enabling the system to economically and efficiently support complex application scenarios.

[0024] This invention provides verifiable data authenticity and granular access control capabilities. The innovative "verifiable state container" designed in this invention comprises two parts: a "state data Merkle tree" and an "access policy Merkle tree," decoupling business data from access policies and providing independent cryptographic commitments. During data sharing, the data provider must provide not only a "first Merkle proof" demonstrating data authenticity but also a "second Merkle proof" demonstrating authorization for the sharing action itself. Through this dual verification, the data consumer can confirm both the integrity of the data and the legitimacy of the access, thereby constructing a secure, end-to-end verifiable data sharing system that does not require trust in third parties.

[0025] This invention ensures the atomicity and eventual consistency of complex business processes confirmed on-chain. For complex business processes consisting of multiple steps with sequential dependencies, this invention generates a "composite state transition proof" by executing the process off-chain, and uses the "zero-knowledge proof" within it to prove the legality of the execution result to the on-chain smart contract. The smart contract does not need to replay or understand any details of the business process; it only needs to execute the verification function once to update the "verifiable state container root hash" representing the system state directly from the old state before the process started to the new state after the process is completed within an atomic transaction. This ensures that the final result of the entire complex business is either completely accepted or completely rejected, fundamentally eliminating the risk of inconsistent system states due to process interruption. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the system architecture of the present invention;

[0027] Figure 2 This is a schematic flowchart of the method of the present invention;

[0028] Figure 3 This is a schematic diagram illustrating the process of generating proof of composite state transitions according to the present invention;

[0029] Figure 4 This is a schematic diagram illustrating the interaction between data sharing and third-party verification in this invention.

[0030] Among them, 110 is the user terminal; 120 is the verifiable state container holding node; 130 is the blockchain network; and 140 is the data consumer. Detailed Implementation

[0031] The technical solutions in 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.

[0032] See attached document Figure 1 , Figure 1 This is a schematic diagram of a system architecture according to an embodiment of the present invention. The present invention provides a blockchain-based trusted storage and sharing system for APP data, which may include:

[0033] User terminal 110 is a computing device that carries an application program. Its function is to generate user operation intentions and hold a private key for signing and authorization.

[0034] Verifiable state container holding node 120 is an off-chain service node whose function is to respond to the operation intention of user terminal 110, perform off-chain calculations, and generate corresponding cryptographic proofs; the verifiable state container holding node 120 interacts with the blockchain network 130 and submits proofs for verification.

[0035] Blockchain network 130, as the system's distributed trust anchor, is equipped with a smart contract system. The function of network 130 is to record authoritative state commitments, verify the legality of proofs submitted by verifiable state container holding node 120, and execute preset protocol logic.

[0036] Data consumer 140 is a third-party entity that needs to access specific data; its function is to request data from verifiable state container holding node 120 and independently perform cryptographic verification on the received data and related proofs.

[0037] In one embodiment of the present invention, the interaction relationship between the above entities is as follows: User terminal 110 sends the user-signed operation intention to verifiable state container holding node 120; Verifiable state container holding node 120 performs the corresponding state change calculation according to the intention, generates a state transition proof, and broadcasts it to blockchain network 130; The smart contract system on blockchain network 130 verifies the proof; After the verification is passed, the authoritative commitment representing the system state is updated; When data consumer 140 needs data, it communicates directly with verifiable state container holding node 120 to obtain data and proof, and uses the authoritative state commitment obtained from blockchain network 130 to complete the verification locally.

[0038] The core data structure managed by the verifiable state container holding node 120 is a verifiable state container, hereinafter referred to as VSC; the VSC is a composite data structure, whose internal structure includes a Merkle tree of state data and a Merkle tree of access policy.

[0039] A Merkle tree for state data is used to store application business data. To protect privacy, the tree is constructed without using the original data key as the path index; instead, it uses the hash value of the data key as the path index.

[0040] The access policy Merkle tree is used to store policy rules for authorizing state changes or data reads; the hash value of each policy rule serves as a leaf node of the tree.

[0041] The root hash of the Merkle tree of the aforementioned state data and the root hash of the Merkle tree of the access strategy, after specific combination and hash calculation, generate a unique VSC root hash; this VSC root hash is the cryptographic commitment of the entire VSC at a specific moment, and is recorded by the smart contract on the blockchain network 130.

[0042] To prove the legality of VSC state changes, two data structures for state transition proofs are defined. The first is a single-step state transition proof, which provides cryptographic evidence for an atomic, single-step state change. This data structure contains Merkel proofs of the authorization policy rules used for this change.

[0043] The second type is the composite state transition proof, which provides a single, concise cryptographic proof for the execution result of a complex business process consisting of multiple steps with sequential dependencies. This data structure includes zero-knowledge proofs, which can prove that the entire business process from the initial state to the final state conforms to the preset policy rules.

[0044] A smart contract system deployed on blockchain network 130 has its functions divided into multiple logical modules; in one embodiment, the system includes:

[0045] The VSC registration and status management module records the authoritative root hash of each VSC and the corresponding holder's pledge information.

[0046] The single-step transition verification module is designed to receive and verify the validity of single-step state transition proofs, specifically by verifying the validity of the Merkel proofs contained therein.

[0047] The composite transition verification module is designed to receive and verify the validity of composite state transition proofs. Specifically, it calls a pre-defined verification algorithm to verify the zero-knowledge proofs contained therein.

[0048] The Active Commitment Protocol module is designed to execute a periodic challenge response mechanism to ensure that the verifiable state container holding node 120 continuously and reliably provides data availability.

[0049] See attached document Figure 2 , Figure 2 This is a flowchart illustrating a blockchain-based trusted storage and sharing method for APP data according to an embodiment of the present invention. The present invention provides a blockchain-based trusted storage and sharing method for APP data, which includes at least the following steps:

[0050] S100: Initialize the verifiable state container, which includes a Merkle tree for state data and a Merkle tree for access policies; and calculate the initial root hash of the verifiable state container based on the root hash of the Merkle tree for state data and the root hash of the Merkle tree for access policies, and record the initial root hash along with the staking information in the smart contract of the blockchain network.

[0051] S200, in response to the state update request, generates a state transition proof according to the type of update, and submits the state transition proof to the smart contract for verification; wherein, the state transition proof includes a single-step state transition proof for proving a single-step atomic update, or a composite state transition proof for proving a multi-step complex process update.

[0052] S300: Once the smart contract verifies the state transition proof, the root hash of the verifiable state container is updated to the new root hash specified in the state transition proof.

[0053] S400, in response to a data consumer's data request, provides the target data value, along with a first Merkel proof and a second Merkel proof to prove the authenticity and legality of the data, for the data consumer to verify locally using the authoritative root hash obtained from the smart contract.

[0054] S500 executes an active commitment protocol, in which smart contracts periodically issue random challenges, and the holder of a verifiable state container must submit valid proof in response to the challenge within a specified time, or their pledged information will be used for slashing.

[0055] The technical implementation details of each of the above steps will be described in detail below through specific embodiments, so that those skilled in the art can better understand and implement the present invention.

[0056] See attached document Figure 1 The method of this embodiment of the invention begins with an initialization and registration phase; the purpose of this phase is to create the infrastructure of a verifiable state container and securely anchor the cryptographic commitment of its initial state to the blockchain network 130.

[0057] S101, Verifiable state container holding node 120 performs an initialization operation off-chain to generate an initial verifiable state container; the initialization operation includes creating two core components of the container: the state data Merkle tree and the access policy Merkle tree.

[0058] In one specific implementation, both the state data Merkle tree and the access policy Merkle tree adopt the Sparse-Merkle-Tree data structure; this data structure is suitable for handling large-scale and non-contiguous key spaces and can generate valid non-existence proofs for non-existent keys.

[0059] The Merkle tree for state data is used to store the application's business data; each data item consists of a key and a value; to prevent the direct exposure of the semantic information of the data item during interaction, the path index of the leaf node of this tree does not use the original key, but rather the result of the key being hashed using a function; the specific generation process of a leaf node is as follows:

[0060] ;

[0061] in: It represents a cryptographic hash function, such as SHA-256; The original key representing the data item; Represents the original value of this data item; This represents the concatenation operation of byte strings; This represents the hash value of the generated leaf node.

[0062] The Merkle tree for access policies is constructed to store policy rules for authorization state changes and data access. Each policy rule is treated as an independent data item and, after hash calculation, is stored as a leaf node in the tree. The specific generation process of a leaf node is as follows:

[0063] ;

[0064] in: Represents the complete structure of a strategy rule; for example, a strategy rule can be defined as a structure containing fields such as subject, object, operation, and condition. This represents the hash value of the generated leaf node.

[0065] In the initial state, the state data Merkle tree can be empty or contain several default business data items; the access policy Merkle tree can contain one or more default policy rules, such as a rule that grants the VSC holder full control over all data.

[0066] S102, after generating the initial state data Merkle tree and access policy Merkle tree, the verifiable state container holding node 120 calculates an initial verifiable state container root hash; this calculation process ensures a unified cryptographic commitment to the two tree states.

[0067] The calculation process first obtains the root hash of the Merkle tree of the state data. and the root hash of the Merkle tree for access strategies Subsequently, these two root hashes are combined with a version number, and the combined result is hashed to obtain the initial verifiable state container root hash. The calculation formula is as follows:

[0068] ;

[0069] in: The root hash of the Merkle tree representing the state data; The root hash of the Merkle tree representing the access strategy; This represents the initial version number of the VSC, and can be set to 0 or 1; This represents the initial VSC root hash obtained from the final calculation.

[0070] S103, the verifiable state container holding node 120 initiates a registration transaction to the VSC registration and state management module deployed on the blockchain network 130 to anchor the initial verifiable state container root hash on the chain.

[0071] The registration transaction must contain at least two parameters: the calculated initial VSC root hash. And a certain amount of pledged assets voluntarily deposited by the holder. .

[0072] Upon receiving the transaction, the VSC registration and state management module executes its internal registration logic. In one specific implementation, this module maintains a mapping data structure to associate and store the VSC holder's blockchain address with VSC information. The registration logic verifies the transaction's validity and creates a new entry for the holder's address in the mapping, which records at least... and the amount of pledged assets After that, This serves as the first authoritative state commitment of the VSC under the consensus of the entire network.

[0073] In one embodiment, the execution of step S200 begins when the verifiable state container holding node 120 receives a state update request. When the request corresponds to an atomic, single-step state change, such as updating a data item or adding a policy rule, the verifiable state container holding node 120 will perform a series of operations to generate a single-step state transition proof. The following uses the updating of a single data item in the Merkle tree of state data as an example to illustrate this process.

[0074] S211, the verifiable state container holding node 120 receives a data update request initiated by user terminal 110; the request contains at least the key of the data to be updated. The new value corresponding to this key And a user signature proving the legitimate origin of the request.

[0075] S212, Verify that the state container holding node 120 searches for a policy rule in its locally maintained Merkle tree that authorizes this update operation. The goal of this search process is to locate a policy rule whose content matches the operational intent of this request; for example, a valid policy rule. It should meet the following requirements: its subject field is consistent with the identity of the request initiator (e.g., a blockchain address), and its object field is consistent with the hash value of the data key being operated on. It is consistent, and its operation field authorizes write operations.

[0076] S213, after successfully locating the authorization policy rule Then, it can be verified that the state container holding node 120, based on the current access policy Merkle tree, is for this... Generate a Merkel proof ;this It is a set of hash values ​​that can be compared with... Together they are used to recalculate and verify the root hash of the tree. Thus prove It is indeed a valid member of the Merkle tree for the current access strategy.

[0077] S214, Verifiable state container holding node 120 performs the requested update operation on its locally maintained Merkle tree of state data; specifically, the operation involves finding the path index as... Find the leaf node and update its content to the new value. hash The update of this leaf node will cause the hash values ​​of all parent nodes on the path from this leaf node to the root of the tree to be recalculated level by level, ultimately generating a new state data Merkle tree root hash. .

[0078] S215, Verifiable state container holding node 120 calculates the new verifiable state container root hash. This calculation process will hash the newly generated state data using a Merkle root hash. Merkel root hash access strategy unchanged in this operation And the incremented new version number The components are combined, and the combined result is hashed; the calculation formula is as follows:

[0079] ;

[0080] in: Represents a cryptographic hash function; The new root hash of the Merkle tree representing the updated state data; The root hash of the Merkle tree representing the access policy that has not changed; This represents the new version number after incrementing; This represents the concatenation operation of byte strings; This represents the final calculated root hash of the new VSC.

[0081] S216, Verifiable state container holding node 120 assembles the components generated in the above steps into a complete single-step state transition proof. ;Should The data structure is as follows:

[0082] ;

[0083] in: The event type representing this state transition is, in this example, set to an identifier indicating a data update; This represents the old VSC root hash that is currently recorded on the chain before this update operation was performed; This represents the new VSC root hash, calculated based on S215, that is expected to be updated on the chain. This represents the proof payload used to demonstrate the legitimacy of this conversion to the on-chain smart contract. This payload contains at least two core components: the authorization policy rules located in S212. And the Merkel proof generated for this rule in S213. .

[0084] See attached document Figure 3 , Figure 3This is a schematic diagram of the composite state transition proof generation process according to an embodiment of the present invention. When the state update request received by the verifiable state container holding node 120 corresponds to a complex business process consisting of multiple steps with dependencies, it will perform a series of operations to generate a composite state transition proof; the following uses an e-commerce order processing process as an example to illustrate this process.

[0085] S221, Verifiable state container holding node 120 models the complex business process to be executed as a directed acyclic graph. The graph is constructed based on business rules predefined in the access policy Merkle tree.

[0086] In this figure, A collection of nodes, each node representing an atomic state change operation; for example, in an e-commerce order processing flow, nodes may include "lock inventory", "create order", "update payment status", etc. It is a set of directed edges, where each edge represents a dependency between nodes; for example, an edge from "Lock Inventory" to "Create Order" means that the execution of the "Create Order" operation depends on the successful completion of the "Lock Inventory" operation.

[0087] The permissions for these operations and their dependencies are defined by the policy rules in the Merkle tree of the access policy; for example, a policy rule can explicitly state that the "lock inventory" operation is only allowed when the inventory status of a certain product in the Merkle tree of the status data is "in stock".

[0088] S222, the verifiable state container holding node 120 in its computing environment, based on the constructed directed acyclic graph. From a known initial verifiable state container root hash The process begins with an off-chain simulation computation; the output of this computation is an execution trajectory, which is referred to as a witness in zero-knowledge proof systems. .

[0089] The simulation calculation strictly follows the figure. The topological order is followed; for each operating node in the graph, holding node 120 will perform the following actions:

[0090] a. Verify whether the prerequisites for this operation have been met in the current simulation state.

[0091] b. Find the policy rule that authorizes the operation from the access policy Merkle tree and generate the corresponding Merkle proof.

[0092] c. Perform the operation in a temporary, temporary state and calculate the new state after the step is completed.

[0093] After the entire simulation calculation is completed, the generated witness It will contain all the information proving the integrity and legitimacy of the entire process; this information will include at least: the initial VSC root hash. The VSC root hash after all intermediate steps are executed, and the final calculated VSC root hash. The data values ​​read or written in each step, and the policy rules used for authorization in each step and their Merkel proofs.

[0094] S223, Verifiable state container holding node 120 utilizes a pre-built zero-knowledge proof circuit. And the witness generated in the previous step Generate a zero-knowledge proof This step forms the core of generating a proof of a composite state transition.

[0095] Zero-knowledge proof circuit It is a computational logic used to mathematically describe and constrain the execution of legal business processes; the circuit is designed to verify the execution trajectory of any business process diagram that follows preset rules; its internal constraints verify at least the following:

[0096] a. For each state transition in the process, is the new VSC root hash correctly calculated based on the old root hash and the data changes for that step?

[0097] b. For each step in the process, is the authorization strategy rule used a valid member of the Merkle tree at that time?

[0098] c. Does the execution order of the entire process follow the dependency relationships defined by the directed acyclic graph?

[0099] The verifiable state container, holding node 120, calls a zero-knowledge proof generation algorithm to witness... As a private input to the algorithm, the starting root hash of the process is also used. and final root hash As a public input To generate proof The formalized representation of this process is as follows:

[0100] ;

[0101] in: Represents the generation algorithm for zero-knowledge proofs; Represents a zero-knowledge proof circuit; This represents a witness that includes the complete execution trajectory; The public input representing this proof contains the following: ; This represents the final generated zero-knowledge proof that proves the entire business process was executed correctly.

[0102] S224, Verifiable state container holding node 120 assembles the components generated in the above steps into a complete composite state transition proof. ;Should The data structure is as follows:

[0103] ;

[0104] in: This represents the old VSC root hash that is currently recorded on the chain before the execution of this complex business process; This represents the final new VSC root hash obtained after the entire process has been correctly executed off-chain; The representation is generated according to S223 and can be mathematically proven from arrive The state transition is a valid and complete zero-knowledge proof.

[0105] Through the above steps, it can be verified that the state container holding node 120 has generated a single, concise, and cryptographically secure composite state transition proof for the entire complex business process. This proof is ready to be submitted to the blockchain network for efficient verification.

[0106] In one embodiment, the execution of step S300 is completed by a single-step transition verification module deployed on the blockchain network 130; this single-step transition verification module receives a single-step state transition proof. Then, a series of verification logic will be executed to confirm the legality of the state transition and to atomically update the state commitment recorded on the chain.

[0107] S311, the single-step transition verification module receives a single-step state transition proof submitted by verifiable state container holder node 120 through a single blockchain transaction. The single-step conversion verification module starts from... The data fields contained within it were parsed out, including the root hash of the old verifiable state container. New verifiable state container root hash and proof of load .

[0108] S312, the single-step conversion verification module performs a preliminary state consistency verification; this module reads the current authoritative VSC root hash associated with the transaction initiator's (i.e., VSC holder's) address from its internal storage and compares it with the received... In The fields are compared; if they are inconsistent, it indicates that... If the state is generated based on an outdated state, the module will reject the state transition and terminate all subsequent operations.

[0109] S313, After passing the preceding state consistency verification, the single-step transition verification module performs an authorization validity verification; this step is the core of verifying whether the single-step state transition has obtained correct authorization; this module proves the load... Extract authorization policy rules and its corresponding Merkel proof .

[0110] To complete the verification, this single-step transition verification module needs to use the root hash of the Merkle tree of the old access strategy prior to this state transition. In one specific implementation, to make the on-chain verification process efficient, the verifiable state container holding node 120 is constructing... At that time, the old state data can be hashed using a Merkle root hash. and older version numbers Also included; the single-step conversion verification module will first use these components to recalculate. and with A comparison is performed to ensure the correctness of the provided components; thereafter, the single-step conversion verification module can directly use the verified components. Subsequent authorization verification is then performed. The specific process for verifying the validity of the authorization involves calling a Merkel proof verification function, the formula of which is as follows:

[0111] ;

[0112] in: This represents the Merkel proof verification function, which returns a boolean value (true or false). The root hash of the Merkle tree representing the old access strategy serves as the trust anchor for verification. Representative on authorization strategy rules The hash value of the leaf node obtained after hash calculation; This represents the Merkel proof corresponding to the leaf node.

[0113] Should The function will utilize The hash value in the middle, from Start by calculating the hashes of the intermediate nodes of the Merkle tree level by level upwards until a calculated root hash is obtained; if the calculated root hash matches the input... If they are completely identical, the function returns true. Proof: It is a valid member in the Merkle tree of the old access strategy; if inconsistent, return false.

[0114] S314, the single-step conversion verification module only performs the on-chain state update operation if the authorization validity verification result of S313 returns true; specifically, this operation involves updating the VSC root hash recorded for the VSC holder in the VSC registration and state management module from... Updated to The specified .

[0115] S315. All verification and update operations from S312 to S314 above are completed within the execution cycle of a single blockchain transaction; this ensures the atomicity of the entire process: if any verification step fails, the entire transaction will be rolled back, and the VSC root hash on the blockchain will remain unchanged, without being partially updated or placed in an inconsistent state.

[0116] In one embodiment, when the proof to be verified is a composite state transition proof... At that time, the execution of step S300 is completed by the composite conversion verification module deployed on the blockchain network 130. The composite conversion verification module is designed to atomically confirm the execution result of a complex off-chain business process in an efficient and deterministic manner, without replaying or verifying any specific business logic of the process on the chain.

[0117] S321, the composite transition verification module receives a composite state transition proof submitted by verifiable state container holding node 120 through a single blockchain transaction. This module is from The data fields contained within it were parsed out, including the root hash of the old verifiable state container. New verifiable state container root hash and zero-knowledge proofs .

[0118] S322, the composite transformation verification module performs a preliminary state consistency verification; this verification step is the same as S312 in the single-step verification, that is, reading and comparing the authoritative VSC root hash of the current record on the chain with the received... In If the two fields do not match, the state transition will be rejected and subsequent operations will be terminated.

[0119] S323, after passing the consistency verification of the preceding state, the composite transformation verification module performs a zero-knowledge proof validity verification; this step is the core of the invention's implementation of atomic confirmation of complex business processes; this composite transformation verification module does not parse or understand the specific content of the off-chain business process, its sole responsibility is to call a pre-built zero-knowledge proof verification function to verify the submitted proof. The mathematical validity.

[0120] In one specific implementation, the zero-knowledge proof verification function can be part of the composite transformation verification module contract code, or, for extreme gas cost optimization, it can be implemented as a precompiled-contract of the blockchain network; the formulaic representation of the verification function is as follows:

[0121] ;

[0122] in: This represents the pre-defined zero-knowledge proof verification function, which returns a boolean value (true or false). Representative from The zero-knowledge proof itself is derived from the analysis; This represents the public input required for this verification; the content of this public input must be consistent with the public input used when generating the proof, i.e. .

[0123] Should The function returns true if and only if the input proof is true. It can be mathematically proven that there exists a non-public computational process (i.e., an off-chain business process) that follows predefined rules, which enables the VSC's state to be derived from the public input specified by the algorithm. legally migrate to The computational complexity of this verification process is independent of the complexity of off-chain business processes, and typically involves only a few elliptic curve multiplications and pairing operations. Therefore, its cost for execution on-chain is constant and low.

[0124] In S324, the composite transformation verification module only performs an on-chain state update operation if the zero-knowledge proof validity verification in S323 returns a true result. This operation is the same as S314 in the single-step verification, that is, updating the VSC root hash recorded in the VSC registration and state management module from... Atomically updated to The specified .

[0125] S325. All verification and update operations from S322 to S324 above are completed within the execution cycle of a single blockchain transaction; this ensures the atomicity of the final confirmation of the entire complex business process; if the zero-knowledge proof verification fails, the entire transaction will be rolled back, and the VSC root hash on the chain will remain unchanged, thereby guaranteeing the consistency and security of the system state.

[0126] See attached document Figure 4 , Figure 4This is a schematic diagram illustrating the interaction between data sharing and third-party verification according to an embodiment of the present invention. In one embodiment, the execution of step S400 involves the interaction between the verifiable state container holding node 120 and the data consumer 140, as well as the independent verification performed locally by the data consumer 140 to ensure the trustworthiness of the data.

[0127] S401, the data consumer 140 initiates a data request to the verifiable state container holding node 120; the request contains at least the identification information of the data it intends to access, such as the data key. .

[0128] S402, Upon receiving the data request, the verifiable state container holding node 120 performs a series of operations to construct a data packet for response. The construction process includes:

[0129] a. Locate a policy rule in its locally maintained Merkle tree that authorizes this data sharing. ;Should The data consumer was explicitly granted permission for 140 key pairs. The corresponding data is read.

[0130] b. Retrieve the key from the Merkle tree of its locally maintained state data. The corresponding current data value .

[0131] c. Generate a first Merkel proof This first Merkel proof is used to prove the authenticity of data, that is, to prove the key. AND value The combination of these is an effective component of the current state data Merkle tree.

[0132] d. Generate a second Merkel proof The second Merkel proof is used to prove the legality of access, that is, to prove the policy rule found in step a. It is an effective component of the current access strategy Merkle tree.

[0133] S403, Data consumer 140 receives data packet Then, a double verification is performed; before performing the verification, the data consumer 140 first obtains the root hash of the authoritative and verifiable state container corresponding to the current network consensus from the VSC registration and state management module of the blockchain network 130. Data consumer 140 The calculation method involves resolving or verifying the Merkle root hash of the current authoritative state data from the verifiable state container held by node 120. and access strategy Merkel root hash These two root hashes will serve as trust anchors for local verification.

[0134] S404, Data consumer 140 performs the first layer of verification, namely data authenticity verification; this verification utilizes data from the data packet... Data values ​​obtained from And the first Merkel proved And the authoritative state data Merkel root hash that has been obtained The formulaic representation of its verification process is as follows:

[0135] ;

[0136] in: Merkel proved the verification function; This represents the verification result, and is a Boolean value. Merkel root hash represents authoritative state data; Represents a cryptographic hash function; The key representing the requested data; This represents the received data value; This represents the concatenation operation of byte strings; This represents the first Merkel proof received.

[0137] Only when Only when it is true can it prove that the received data value is true. Indeed, this VSC version has a key issue. Related, authentic, and unaltered data.

[0138] S405, Data consumer 140 performs a second layer of verification, namely access legitimacy verification; this verification utilizes the data packet... The strategy rules obtained from Second Merkel Proof And the authoritative access strategy Merkel root hashing that has been obtained The formulaic representation of its verification process is as follows:

[0139] ;

[0140] in: This represents the verification result, and is a Boolean value. Merkel root hashing is an access strategy representing authority. This represents the policy rules received, which are allegedly authorized for this sharing; This represents the second Merkel proof received.

[0141] Only when Only when the result is true can it be proven that the act of the verifiable state container holding node 120 providing this data to the data consumer 140 is a legitimate act that has been explicitly authorized by the valid policy rules in VSC.

[0142] S406, Data consumer 140 will only ultimately accept the received data value if both the data authenticity verification in S404 and the access legitimacy verification in S405 are true. If any verification fails, the data consumer 140 will reject the data, thereby avoiding security risks caused by data tampering or unauthorized access.

[0143] In one embodiment, the execution of step S500 is led by an active commitment protocol module deployed on the blockchain network 130, the purpose of which is to continuously verify the data availability and online status of the verifiable state container holding node 120.

[0144] S501, the active commitment protocol module initiates a random challenge at a preset period or under externally triggered conditions. In one specific implementation, the generation of this random number can utilize the inherent randomness of the blockchain, such as the output of a verifiable random function (VRF) or the hash value of a future specific block, to ensure the unpredictability of the challenge. The content of the challenge is a randomly generated data key. .

[0145] S502, after generating a challenge, the active commitment protocol module broadcasts a challenge event to the blockchain network; this event includes at least the address of the holder of the verifiable state container being challenged, the challenge content, and the data key. And a deadline for a response.

[0146] S503, the verifiable state container holding node 120 acts as the responder, which needs to continuously listen to and parse events broadcast by the live commitment protocol module; when it hears a challenge event pointing to itself, the node searches for the challenge data key in its local Merkle tree of state data. The corresponding data value Subsequently, the node, based on the current Merkle tree of the state data corresponding to the on-chain authoritative VSC root hash, generates the data item. Generate a Merkel proof Finally, this node will contain data values ​​before the deadline timestamp. And Merkel's proof The response data is submitted to the Active Commitment Protocol module through a single blockchain transaction.

[0147] S504, upon receiving a response transaction, the active commitment protocol module first checks whether the transaction has been confirmed before the specified deadline. If it has not timed out, the active commitment protocol module will perform a Merkle proof verification to confirm the validity of the response data. The active commitment protocol module first obtains the current authoritative VSC root hash from the VSC registration and state management module. And parse out the corresponding state data Merkle root hash from it. This serves as a trust anchor for verification; the formulaic representation of its verification process is as follows:

[0148] ;

[0149] in: This represents the Merkel proof verification function, which returns a boolean value. This represents the verification result; Merkel root hash represents authoritative state data; Represents a cryptographic hash function; Data keys representing challenges; This represents the data values ​​contained in the response; This represents the concatenation operation of byte strings; This represents the Merkel proof included in the response.

[0150] S505, the active commitment protocol module executes a decision based on the verification result of S504; if the response is not received before the deadline timestamp, or the verification result in S504... If the result is false, the active commitment protocol module will automatically execute a forfeiture operation. Specifically, the active commitment protocol module calls a function in the VSC registration and status management module to extract funds from the pledged assets recorded by the VSC holder. In the process, a preset percentage or fixed amount of assets will be deducted and transferred to a designated address, such as a destruction address or a community vault; if the response is received and verified in a timely manner, the holder is considered to have passed the activity check and their pledged assets will not be affected.

[0151] To improve the economy and adaptability of the present invention in practical applications, the embodiments of the present invention also include several system optimization mechanisms and scalability designs.

[0152] In one embodiment, to reduce the transaction costs (Gas costs) incurred in performing state updates on the blockchain network 130, the present invention provides a batch processing mechanism; this mechanism aims to amortize a fixed transaction base cost by processing multiple consecutive single-step state transitions in a single transaction. The specific implementation of this mechanism is as follows:

[0153] S601, verifiable state container holding node 120 accumulates multiple consecutive single-step state transition proofs locally. ;These Form an ordered sequence, where the first... The root hash of the old verifiable state container of the proof Must be equal to the first The new verifiable state container root hash of the proof .

[0154] S602, Verifiable state container holding node 120 will... The sequence is passed as an array parameter and, through a single blockchain transaction, invokes a specially designed batch processing function in the single-step conversion verification module.

[0155] S603, when the single-step conversion verification module executes this batch processing function, it first performs an initial state consistency verification, that is, the first one in the verification sequence. of Is it consistent with the authoritative VSC root hash of the current record on the chain?

[0156] S604, after successful verification, this single-step conversion verification module will traverse the entire... An array; in each iteration, this single-step transformation verification module performs the same authorization validity verification as S313, and simultaneously verifies the sequence continuity condition in S601.

[0157] S605, only when all elements in the array are... Only when all verifications are successful and the sequence continuity is guaranteed will the single-step transformation verification module perform an on-chain state update operation; this operation will update the VSC root hash recorded on the chain, starting from the first hash in the sequence. of Update directly to the last one in the sequence. of If any proof fails during the traversal, the entire transaction will be rolled back.

[0158] The application of zero-knowledge proofs in this invention significantly optimizes the verification cost of complex operations. If a traditional method without the core features of this invention is used—that is, directly executing a complex business logic consisting of N steps on the blockchain—its transaction cost is significantly lower. This will be directly proportional to the complexity of the business logic, that is... ,in It refers to the number of operation steps; this means that the more complex the business logic, the higher the on-chain verification cost.

[0159] In contrast, this invention separates the execution and verification processes of complex business logic, thus keeping the on-chain verification cost constant. Off-chain computation handles all complex business steps, while the on-chain composite transformation verification module only needs to execute the zero-knowledge proof verification function once. The computational complexity of this function is primarily related to the size of the proof itself and the number of common inputs, while its complexity is related to the number of steps in the off-chain computation process being proven. Its transaction costs are unrelated to its inherent complexity; therefore, its transaction costs are... It can be approximated as a constant that is independent of business complexity. ,Right now This makes the cost of atomic confirmation on the blockchain predictable and low, regardless of how complex the off-chain business process is.

[0160] Furthermore, the technical framework of this invention is highly flexible and scalable. The smart contract system described in this invention relies on standard cryptographic primitives, such as hash functions and elliptic curve operations, and therefore can be deployed on any blockchain platform that supports smart contracts. These platforms include, but are not limited to, first-layer (Layer 1) blockchains such as Ethereum, and second-layer (Layer 2) scaling solutions such as Optimistic-Rollups or ZK-Rollups. When deployed on a second-layer solution, transaction costs can be further reduced and confirmation speed can be improved.

[0161] The internal data structure of the verifiable state container defined in this invention is also variable; in the above embodiments, both the state data Merkle tree and the access policy Merkle tree can be sparse Merkle trees; however, depending on the specific application scenario, other Merkle tree variants can also be used; for example, for applications with dense key spaces, a standard Merkle tree can be used to optimize storage space; for scenarios requiring compatibility with the Ethereum state model, a Merkle-Patricia-Trie can be used; similarly, the hash function used... Alternatively, the choice can be made based on the characteristics of the target blockchain platform. For example, Keccak-256 can be used in the Ethereum environment, while Poseidon and other hash functions can be used in environments that are friendly to zero-knowledge proofs. These variations do not deviate from the core idea of ​​this invention to ensure data trustworthiness through cryptographic commitments.

Claims

1. A blockchain-based method for trusted storage and sharing of APP data, characterized in that, Includes the following steps: Initialize a verifiable state container, which includes a Merkle tree of state data and a Merkle tree of access policies; An initial verifiable state container root hash is calculated, and the calculated initial verifiable state container root hash is recorded together with the staking information in the smart contract of the blockchain network. In response to a state update request, a state transition proof is generated based on the type of update, and the generated state transition proof is submitted to the smart contract for verification. The state transition proof includes a single-step state transition proof for proving a single-step atomic update, or a composite state transition proof for proving a multi-step complex process update. The steps for generating a single-step state transition proof include: searching for an authorization policy rule in the access policy Merkle tree that can authorize the current single-step atomic update, and generating a Merkle proof for the found authorization policy rule; performing an update operation on the state data Merkle tree to generate a new root hash of the state data Merkle tree; calculating a new root hash based on the newly generated root hash of the state data Merkle tree; and assembling the old verifiable state container root hash, the calculated new root hash, and the proof payload containing the authorization policy rule and the Merkle proof of the authorization policy rule into a single-step state transition proof. The steps for generating a composite state transition proof include: modeling the multi-step complex process update as a directed acyclic graph (DAG), and performing a simulation calculation in an off-chain environment based on the established DAG to generate a witness to the execution trajectory; using a pre-built zero-knowledge proof circuit, taking the generated witness as private input and the starting root hash and the final root hash of the process as public input to generate a zero-knowledge proof; and assembling the starting root hash, the final root hash, and the generated zero-knowledge proof into a composite state transition proof. Once the smart contract verifies the state transition proof, the root hash of the verifiable state container recorded in the smart contract is updated to the new root hash specified in the generated state transition proof.

2. The blockchain-based trusted storage and sharing method for APP data according to claim 1, characterized in that, The steps to calculate an initial verifiable state container root hash include: Obtain the root hash of the Merkle tree of the state data and the root hash of the Merkle tree of the access strategy, respectively; The root hash of the Merkle tree of the state data, the root hash of the Merkle tree of the access policy, and a version number are combined, and the combined result is hashed to obtain the root hash of the initial verifiable state container.

3. The blockchain-based trusted storage and sharing method for APP data according to claim 1, characterized in that, The steps for a smart contract to verify a single-step state transition proof include: Perform a preliminary state consistency verification to confirm that the old verifiable state container root hash in the submitted single-step state transition proof is consistent with the root hash of the current record in the smart contract. Extract the authorization policy rule and its Merkle proof from the proof load, and call a Merkle proof verification function to verify that the authorization policy rule is a valid member of the access policy Merkle tree.

4. The blockchain-based trusted storage and sharing method for APP data according to claim 1, characterized in that, The steps for a smart contract to verify a compound state transition proof include: Perform a preliminary state consistency verification to confirm that the starting root hash in the submitted composite state transition proof is consistent with the root hash of the current record in the smart contract; Call the pre-built zero-knowledge proof verification function, and use the zero-knowledge proof in the submitted composite state transition proof and the common input to verify that the multi-step complex process update is correctly executed off-chain.

5. The blockchain-based trusted storage and sharing method for APP data according to claim 1, characterized in that, The method further includes: In response to a data consumer's data request, the system provides a target data value, a first Merkel proof to prove the authenticity of the data, and a second Merkel proof to prove the legitimacy of access, for the data consumer to perform local independent verification using the root hash of the authoritative verifiable state container obtained from the smart contract.

6. The blockchain-based trusted storage and sharing method for APP data according to claim 5, characterized in that, Local independent authentication includes one two-factor authentication, which includes: Perform the first verification, using the first Merkle proof, to verify that the target data value is a valid component of the state data Merkle tree; A second layer of verification is performed, using a second Merkle proof, to verify that a policy rule for authorized data sharing is a valid component of the access policy Merkle tree; The target data value is accepted only if both the first and second verifications pass.

7. The blockchain-based trusted storage and sharing method for APP data according to claim 1, characterized in that, The method further includes executing an activity commitment protocol, the activity commitment protocol comprising: The smart contract periodically initiates a random challenge containing randomly generated data keys; The holder of the verifiable state container shall, within a specified time, submit the data value corresponding to the randomly generated data key and a Merkel proof of the data value as a response. If the holder of the verifiable state container fails to submit a valid response within the specified time, the smart contract will execute a forfeiture operation on the recorded staking information.

8. The blockchain-based trusted storage and sharing method for APP data according to claim 1, characterized in that, The step of submitting state transition proofs to a smart contract for verification, as a batch processing mechanism, includes: Accumulate multiple consecutive single-step state transition proofs locally, where the root hash of each old verifiable state container is equal to the new root hash of the previous one, to form a proof sequence. The generated proof sequence is submitted to the smart contract through a single blockchain transaction; The smart contract verifies each single-step state transition proof in the proof sequence, and after all verifications pass, the root hash of the verifiable state container recorded in the smart contract is directly updated from the old root hash of the first proof in the sequence to the new root hash of the last proof in the sequence.

Images