A blockchain privacy computing method and system based on a dynamic ciphertext storage engine

Abstract

The application discloses a kind of based on dynamic secret state storage engine's blockchain privacy calculation method and system, the calculation method includes: step S1: initialization and state machine deployment;Step S2: calculation task release and key negotiation;Step S3: data secret state and layered storage certificate;Step S4: secret state calculation execution and state storage certificate;Step S5: storage certificate aggregation and batch chain;Step S6: storage certificate verification;Step S7: verifiable decryption and final storage certificate.The storage certificate event of continuous state conversion is aggregated into Merkle tree, and only the root is chained, which significantly reduces the storage cost while ensuring verifiability.

Description

Technical Field

[0001] This invention relates to the field of blockchain and privacy computing integration applications, and in particular to a blockchain privacy computing method and system based on a dynamic encrypted evidence storage engine. Background Technology

[0002] In applications integrating blockchain and privacy computing, existing technologies cannot achieve traceability and verifiable evidence storage of the entire encrypted computing process, leading to a structural contradiction between privacy protection requirements and audit and regulatory needs. Specifically, in existing technical solutions, the encrypted computing process (such as homomorphic encrypted computing, multi-party secure computing, and trusted execution environment computing) is a "black box" for the blockchain—the blockchain can only perceive the initiation of the computing task and the submission of the final result, but cannot know the legality of the intermediate states, the integrity of the operation sequence, or the compliance of the actions of each participant. This results in a lack of auditable computing process support for the encrypted computing results, and in scenarios requiring regulatory intervention (such as financial risk control and medical data compliance audits), regulators cannot verify the correctness of the computing process without obtaining the original data.

[0003] Blockchain technology, with its decentralized, immutable, and traceable characteristics, provides a trusted infrastructure for data sharing and collaborative computing. However, blockchain itself suffers from security issues such as on-chain data transparency and a lack of privacy protection in smart contract execution environments. Privacy-preserving computation technologies (including homomorphic encryption, secure multi-party computation, trusted execution environments, and federated learning) can achieve data computation and analysis while protecting data privacy. Integrating blockchain with privacy-preserving computation leverages both the trusted storage and audit traceability capabilities of blockchain and the protection of data privacy through privacy-preserving computation, making it a crucial technology in the secure circulation of data elements.

[0004] The existing relevant technical solutions mainly include the following categories: A. Layered architecture solution Representative solutions include a three-layer architecture of "edge computing layer - privacy computing layer - blockchain layer," which constructs a distributed privacy computing system through the deep integration of technologies such as federated learning, homomorphic encryption, and blockchain. The core idea of ​​this type of solution is to deploy privacy computing as an independent layer on top of the blockchain, and after the privacy computing layer completes the computation, it submits the result to the blockchain layer for notarization. Another example is a three-layer protection architecture of "blockchain layer - host layer - TEE layer," which deeply integrates confidential computation with the verification of the integrity of the original data, using the blockchain to store immutable data fingerprints as a trusted anchor.

[0005] B. On-chain coordination + off-chain computation solution A representative solution is the "Hidden State-Based Blockchain Smart Contract Method and System," which includes on-chain components and off-chain high-performance decryption nodes. The on-chain smart contract publishes proposals and Paillier public keys, and performs homomorphic aggregation on multiple encrypted transaction data to obtain encrypted transaction results. The off-chain high-performance decryption node retrieves the encrypted transaction results from the smart contract, decrypts them, and returns the plaintext to the smart contract. This type of solution addresses the performance bottleneck of homomorphic encryption through a hybrid architecture of "on-chain coordination and off-chain computation."

[0006] C. Homomorphic Encryption On-Chain Computational Schemes Representative solutions include "a joint statistical method based on blockchain and privacy computing technologies," where the data querying party generates homomorphic encryption public and private keys, encrypts keywords, and sends them to the blockchain. The blockchain then performs homomorphic addition on multiple result ciphertexts to obtain a joint statistical ciphertext, which is returned. Another example is "an asset query method based on blockchain homomorphic encryption," where each participant homomorphically encrypts their asset balance and uploads it to the blockchain, then obtains the total query amount through homomorphic addition.

[0007] D.TEE Integration Solution A representative approach involves building a main chain by deploying blockchain consensus nodes in the cloud, deploying computing nodes in a two-layer trusted execution environment hardware to build sub-chains according to business types, and establishing a main chain-sub-chain architecture through cross-chain communication protocols.

[0008] E. Secure multi-party computation solution Introducing secure multi-party computation into the blockchain ecosystem involves performing multi-party computations through function operations under encrypted conditions. Related research applies blockchain to secure multi-party computation, federated learning, and trusted execution environments. Other solutions utilize secret sharing protocols to shard private data, with each shard generating sub-data according to preset rules and distributing it to participating parties.

[0009] F. Evidence Preservation Related Schemes Existing evidence preservation schemes mostly involve storing the final results or data hashes of privacy-preserving computation tasks on the blockchain. For example, a privacy-preserving information retrieval system based on blockchain and function secret sharing constructs an index using symmetric encryption and Bloom filters, combining blockchain evidence preservation with distributed storage to transmit the encrypted file hash value and index table to the blockchain for on-chain storage. Another example is the "tamper-proof, secure, and efficient data collaborative computing system," which utilizes blockchain to store immutable data fingerprints as trusted anchors.

[0010] Existing technical solutions generally suffer from the following drawbacks: Disadvantage 1: The evidence storage and dense state calculation processes are separated, lacking full traceability.

[0011] In existing solutions, the objects of evidence storage are mostly the final result of cryptographic computation or the static hash of the original data. The evidence storage occurs after the computation is completed, which is a kind of "result evidence storage" rather than "process evidence storage". The cryptographic computation process itself (including each step of the cryptographic operation and each state transition) is not visible to the blockchain, and the entire lifecycle of the computation cannot be traced on the chain. When it is necessary to audit the result of cryptographic computation, the auditor can only see "who submitted what result at what time", but cannot verify "how this result was calculated, what operations were involved, and whether each operation was legal".

[0012] Disadvantage 2: There is a lack of a unified evidence storage framework for different dense state calculation paths.

[0013] In existing solutions, different privacy-preserving computation paths, such as homomorphic encryption, multi-party secure computation, and trusted execution environments, have developed independently without forming a unified evidence preservation framework. The computation processes and result formats generated by different computation paths vary, leading to inconsistent evidence preservation formats and incompatible verification logic, making it difficult to achieve unified auditing in cross-path scenarios.

[0014] Disadvantage 3: The evidence storage granularity is coarse and cannot support fine-grained auditing.

[0015] Existing evidence storage schemes mostly adopt the "overall hashing on-chain" approach, with evidence storage granularity at the level of the entire dataset or the entire computation result. When it is necessary to audit a specific operation in the encrypted computation (such as a specific ciphertext multiplication or a specific key usage), it is impossible to extract independent evidence of that operation from the coarse overall evidence storage.

[0016] Disadvantage 4: There is a lack of dynamic correlation between evidence storage and verification.

[0017] In existing schemes, evidence storage is static—once it's on the blockchain, it's no longer associated with subsequent computation processes. Each step of the encrypted computation lacks a cryptographic link established through evidence storage, and there are no verifiable pointer links between preceding and subsequent states, making it impossible to form a complete "chain of computational evidence."

[0018] Disadvantage 5: There is tension between privacy protection and evidence verification.

[0019] Privacy-preserving computation requires that "data is available but not visible," while evidence verification requires that "the process is verifiable." In existing solutions, verifiers often need to obtain a certain amount of plaintext information or intermediate results to verify the correctness of the computation, which conflicts with the goal of privacy protection. Although some solutions have introduced technologies such as zero-knowledge proofs to try to alleviate this contradiction, zero-knowledge proofs can only prove the correctness of the computation result, but cannot prove the integrity and compliance of each stage of the computation process.

[0020] Disadvantage 6: Lack of evidence storage capability for the time dimension of dense state computation.

[0021] In application scenarios that require time constraints (such as timed decryption, delayed auditing, and time-series data compliance), existing evidence preservation solutions cannot prove that "a certain encrypted calculation result was completed before a specific time" without exposing the data content. Summary of the Invention

[0022] In view of the above problems, the present invention is proposed to provide a blockchain privacy computing method and system based on a dynamic encrypted evidence storage engine to overcome or at least partially solve the above problems.

[0023] According to one aspect of the present invention, a blockchain privacy computation method based on a dynamic encrypted evidence storage engine is provided, the computation method comprising: Step S1: Initialization and state machine deployment; Step S2: Publish computation task and negotiate key; Step S3: Data encryption and layered evidence storage; Step S4: Execution of dense-state computation and state-by-state evidence storage; Step S5: Evidence aggregation and batch on-chain storage; Step S6: Verification of evidence; Step S7: Verify decryption and final evidence storage.

[0024] Optionally, step S1: initialization and state machine deployment specifically includes: Step S1.1: Deploy the secure state machine smart contract on the blockchain network, and define the state set S and the state transition rule T; Step S1.2: Each participant registers their identity in the system and generates their own key materials. The participants include data providers, data users, computing nodes, and auditors. Step S1.3: The state machine enters the initialization state S0, generates the initial evidence storage event E0, and uploads it to the chain.

[0025] Optionally, step S2: computation task publishing and key negotiation specifically includes: Step S2.1: The data user publishes a cryptographic computation task through a smart contract, specifying the computation function, participant requirements, and privacy level.

[0026] Step S2.2: Each participant completes key negotiation according to the task requirements, including the generation of homomorphic encryption public and private keys and the generation of MPC secret sharing shares; Step S2.3: After the key is ready, the state machine transitions from S0 to S1, generating a notarization event E1 and uploading it to the chain; notarization event E1 contains the cryptographic commitment of the public keys of each participating party.

[0027] Optionally, step S3: data encryption and hierarchical evidence storage specifically includes: Step S3.1: The data provider performs densification processing on the raw data according to the selected computation path. If a homomorphic encryption path is selected, the data will be encrypted using a homomorphic encryption algorithm; If the MPC path is selected, the data will be fragmented using a secret sharing protocol; If the TEE path is selected, the data will be loaded within the Trusted Execution Environment; Step S3.2: Calculate the cryptographic commitment of the ciphertext data, store the ciphertext data in an off-chain distributed storage network, and submit the commitment value to the blockchain.

[0028] Step S3.3: The state machine transitions from S1 to S2, generating a storage event E2 and uploading it to the blockchain; the storage event E2 includes: a cryptographic commitment to the encrypted data, a zero-knowledge proof of the encryption operation, and the identity evidence of the data provider.

[0029] Optionally, step S4: dense state calculation execution and state-by-state evidence storage specifically includes: Step S4.1: The smart contract selects the optimal computation path based on the computation task parameters; Step S4.2: Perform dense-state computation along the selected computation path. After each dense-state operation is completed, the state machine performs a state transition. Step S4.3: Each state transition automatically triggers the generation of a notarization event. The notarization event includes: the current state identifier and the global state sequence number, the operation type identifier, the participant identifier, the cryptographic commitment of the computation input, the cryptographic commitment of the computation output, the zero-knowledge proof of the computation correctness, and the hash pointer of the notarization event of the previous state. Step S4.4: The state machine sequentially undergoes multiple transitions, including the dense state calculation S3 and the phased completion S4. Each transition generates a corresponding evidence storage event and uploads it to the blockchain. Step S4.5: After all the dense state calculation tasks are completed, the state machine transitions to the calculation completion S5 and generates the evidence storage event E_complete.

[0030] Optionally, step S5: evidence aggregation and batch on-chain storage specifically includes: Step S5.1: The evidence generation layer aggregates multiple consecutive evidence-preserving events into a Merkle tree; Step S5.2: Calculate the Merkle root hash, and submit the Merkle root and the Merkle path of each evidence storage event as evidence storage transactions to the blockchain; Step S5.3: The blockchain packages the evidence storage transaction into a block, and writes the evidence storage root hash into the block header; Step S5.4: The original evidence event data is stored off-chain, and the existence of a specific evidence event is verified when needed via the Merkle path.

[0031] Optionally, step S6: evidence verification specifically includes: Step S6.1 The verifier obtains the root hash of the evidence storage block from the blockchain; Step S6.2 The verifier obtains the evidence storage event data and Merkle path to be verified from off-chain; Step S6.3 The verifier performs verification in the following manner: After all verifications are passed in step S6.4, the state machine transitions to Verification Pass S6, generating the evidence storage event E_verify.

[0032] Optionally, step S6.3, where the verifier performs verification in the following manner, specifically includes: The Merkle path was used to verify that the evidence storage event was indeed included in the evidence storage block; Verify the continuity and integrity of the state transition sequence using the preceding hash pointer; The correctness of each dense-state calculation is verified using zero-knowledge proofs; Verify the consistency of input and output data using commitment values.

[0033] Optionally, step S7: verifying decryption and final evidence storage specifically includes: Step S7.1: Determine whether the preset decryption conditions are met, including the end of the time delay, multi-party authorization, and compliance review approval; Step S7.2: If a time delay requirement is involved, the verifier can verify the delay function proof and confirm that the decryption time meets the preset conditions; Step S7.3: Perform the decryption operation. The decryption process is also recorded as a state transition. Step S7.4: The state machine transitions to decryption ready S7, generating the final evidence storage event E_final, forming a complete encrypted computation evidence storage chain from S0 to S7.

[0034] This invention also provides a blockchain privacy computing system based on a dynamic encrypted evidence storage engine, applying the aforementioned blockchain privacy computing method based on a dynamic encrypted evidence storage engine. The computing system includes: The initialization and deployment module is used for initialization and state machine deployment; The adaptive routing module is used for computation task publishing and key negotiation; The layered evidence storage module is used for data encryption and layered evidence storage; The state machine module for dense-state evidence storage is used for dense-state computation execution and state-by-state evidence storage. The evidence generation module is used for evidence aggregation and batch on-chain storage; The verification module is used for evidence verification. The decryption module is used for verifiable decryption and final evidence storage.

[0035] This invention provides a blockchain privacy computing method and system based on a dynamic encrypted evidence storage engine. The computing method includes: Step S1: Initialization and state machine deployment; Step S2: Computation task release and key negotiation; Step S3: Data encryption and layered evidence storage; Step S4: Enforcing encrypted computation and state-by-state evidence storage; Step S5: Evidence aggregation and batch on-chain storage; Step S6: Evidence verification; Step S7: Verifiable decryption and final evidence storage. By aggregating the evidence storage events of continuous state transitions into a Merkle tree and only putting the root on-chain, storage costs are significantly reduced while ensuring verifiability.

[0036] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0037] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 A flowchart illustrating a blockchain privacy computation method based on a dynamic encrypted evidence storage engine, provided for an embodiment of the present invention; Figure 2 This invention provides an overall framework diagram of a blockchain privacy computing system based on a dynamic encrypted evidence storage engine, as shown in the embodiments of the present invention. Figure 3 This is a state transition diagram of the closed-state evidence storage state machine provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of a layered evidence storage architecture provided in an embodiment of the present invention. Detailed Implementation

[0039] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0040] The terms "comprising" and "having," and any variations thereof, in the specification, embodiments, claims, and drawings of this invention are intended to cover non-exclusive inclusion, such as including a series of steps or units.

[0041] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0042] like Figure 1 As shown, a blockchain privacy computing method based on a dynamic encrypted evidence storage engine is disclosed. The computing method includes: step S1: initialization and state machine deployment; step S2: computing task release and key negotiation; step S3: data encryption and layered evidence storage; step S4: encrypted computing execution and state-by-state evidence storage; step S5: evidence storage aggregation and batch on-chain; step S6: evidence storage verification; step S7: verifiable decryption and final evidence storage.

[0043] A blockchain privacy computing method based on a dynamic encrypted evidence storage engine includes: Step 1: System Initialization and State Machine Deployment 1.1 Deploy a secure state machine smart contract on a blockchain network, defining a state set S and a state transition rule T.

[0044] 1.2 Each participant (data provider, data user, computing node, and auditor) registers their identity in the system and generates their respective key materials.

[0045] 1.3 The state machine enters S0 (initialization state), generates the initial evidence storage event E0 and uploads it to the chain.

[0046] Step 2: Publish Computation Task and Negotiate Key 2.1 Data users publish encrypted computing tasks through smart contracts, specifying the computing function, participant requirements, and privacy level.

[0047] 2.2 Each participating party shall complete key negotiation according to the task requirements (such as generating homomorphic encryption public and private keys and generating MPC secret sharing shares).

[0048] 2.3 Once the key is ready, the state machine transitions from S0 to S1, generating a notarization event E1 and uploading it to the blockchain. E1 contains the cryptographic commitments of each participant's public key (but does not contain private key information).

[0049] Step 3: Data Encryption and Layered Evidence Storage 3.1 The data provider performs data densification processing on the raw data based on the selected computation path: If a homomorphic encryption path is selected, the data will be encrypted using a homomorphic encryption algorithm; If the MPC path is selected, the data will be fragmented using a secret sharing protocol; If the TEE path is selected, the data will be loaded within the Trusted Execution Environment.

[0050] 3.2 Calculate the cryptographic commitment to the ciphertext data, store the ciphertext data in an off-chain distributed storage network, and submit the commitment value to the blockchain.

[0051] 3.3 The state machine transitions from S1 to S2, generating and uploading the evidence storage event E2 to the blockchain. E2 includes: Cryptographic commitments to encrypted data (anchoring of L3 evidence); Zero-knowledge proof of encryption operations (proving that encryption operations are executed correctly without revealing plaintext); Evidence of the data provider's identity (protected by group signature).

[0052] Step 4: Dense-state computation execution and state-by-state proof 4.1 The smart contract selects the optimal computation path through the adaptive computation routing module based on the computation task parameters.

[0053] 4.2 Perform dense-state computation along the selected computation path. After each dense-state operation (such as homomorphic addition, homomorphic multiplication, MPC round interaction, TEE internal computation, etc.), the state machine performs a state transition.

[0054] 4.3 Each state transition automatically triggers the generation of a notarization event, which includes: The current state identifier and global state sequence number, operation type identifier, participant identifier (protected by group signature or ring signature), cryptographic commitment to the computation input, cryptographic commitment to the computation output, zero-knowledge proof of computation correctness, and hash pointer of the preceding state storage event.

[0055] 4.4 The state machine goes through multiple transitions in sequence, from S3 (dense state calculation) to S4 (stage completion). Each transition generates a corresponding evidence storage event and uploads it to the blockchain.

[0056] 4.5 After all the dense state calculation tasks are completed, the state machine transitions to S5 (calculation completed) and generates the evidence storage event E_complete.

[0057] Step 5: Evidence Aggregation and Batch On-Chain Deployment 5.1 The evidence generation layer aggregates multiple consecutive evidence events generated in step four into a Merkle tree.

[0058] 5.2 Calculate the Merkle root hash and submit the Merkle root and the Merkle path of each evidence-preserving event as evidence-preserving transactions to the blockchain.

[0059] 5.3 The blockchain packages the evidence-based transactions into a block, and writes the evidence root hash into the block header.

[0060] 5.4 The original evidence event data (including evidence bodies such as zero-knowledge proofs) is stored off-chain, and the existence of a specific evidence event can be verified when needed through the Merkle path.

[0061] Step Six: Evidence Verification 6.1 The verifier (data user or auditor) obtains the root hash of the evidence block from the blockchain.

[0062] 6.2 The verifier obtains the evidence storage event data to be verified and its Merkle path from off-chain.

[0063] 6.3 The verifier shall perform the following verifications: The Merkle path was used to verify that the evidence storage event was indeed included in the evidence storage block; Verify the continuity and integrity of the state transition sequence using the preceding hash pointer; The correctness of each dense-state calculation is verified using zero-knowledge proofs; Verify the consistency of input and output data using commitment values.

[0064] 6.4 After all verifications are successful, the state machine transitions to S6 (verification successful), generating the evidence storage event E_verify.

[0065] Step 7: Verifiable decryption and final evidence storage 7.1 Determine whether the preset decryption conditions are met (such as the end of the time delay, multi-party authorization, compliance review approval, etc.).

[0066] 7.2 If time delay is required, the verifier can verify the delay function proof and confirm that the decryption time meets the preset conditions.

[0067] 7.3 Perform the decryption operation. The decryption process is also recorded as a state transition.

[0068] 7.4 The state machine transitions to S7 (decryption ready), generating the final evidence storage event E_final, forming a complete encrypted computation evidence storage chain from S0 to S7.

[0069] Subprocess A: Evidence Aggregation and Compression Algorithm To reduce on-chain storage overhead, this invention employs the following aggregation strategy: A1. Treat every N consecutive state transition events as an aggregation unit (N is a configurable parameter, with a default value of 100).

[0070] A2. Construct a Merkle tree using the evidence-preserving events within the aggregation unit as leaf nodes.

[0071] A3. Upload the Merkle root, the start and end state identifiers of the aggregation unit, and the time interval as aggregated evidence records onto the blockchain.

[0072] A4. When verifying a specific evidence event, the verifier obtains the event data and its Merkle path from off-chain and verifies its existence through the Merkle root.

[0073] A5. When it is necessary to verify the entire state transition sequence, the verifier verifies the Merkle root of each aggregation unit and its preceding and following relationships in turn.

[0074] Subprocess B: Audit traceability for privacy protection B1. The auditor registers their audit identity in the system and generates an audit public-private key pair.

[0075] B2. The auditor submits an audit request to the blockchain, along with a zero-knowledge proof generated using the audit private key, proving that it has legitimate audit authority.

[0076] B3. The smart contract verifies zero-knowledge proofs. After confirming audit permissions, the auditor is granted access to the metadata of the evidence storage event.

[0077] B4. The auditor obtains metadata such as the state sequence, operation type, timestamp, and group signatures of the participants in the evidence-preserving event, but does not obtain any plaintext information of the original data.

[0078] B5. Auditors can verify the correctness of the calculation process by validating zero-knowledge proofs and commitment values ​​without accessing the original data.

[0079] Subprocess C: Exception handling C1. The state transition engine verifies the transition conditions before each state transition. If the transition conditions are not met (such as the confidential calculation result being inconsistent with the commitment value, or the participant's signature verification failing), the state machine does not execute the transition.

[0080] C2. When the state machine enters the abnormal state S_error, it generates an abnormal evidence event E_error, which records information such as the abnormal type, the time of occurrence, and the parties involved.

[0081] C3. The smart contract executes a preset recovery strategy (such as retrying, rolling back to the previous state, notifying the administrator, etc.) based on the type of exception.

[0082] C4. All abnormal states and recovery operations are recorded as state transitions to ensure that the abnormal handling process is also traceable.

[0083] Subprocess D: Verifiable delayed evidence storage D1. In scenarios where a time delay needs to be applied to the results of encrypted computation (such as timed decryption, delayed auditing, etc.), the computing node generates a proof of the verifiable delay function (VDF) after completing the encrypted computation.

[0084] D2. The VDF proof is uploaded to the blockchain along with the evidence storage event, proving that "before a certain point in time, the calculation result has been generated but has not yet been decrypted".

[0085] D3. After the preset delay time, any verification party can use VDF to prove whether the verification delay time meets the requirements.

[0086] D4. After the delay period expires, perform the decryption operation, decrypt the evidence storage event record, record the decryption time, and verify it with the VDF proof to ensure that the time order of "first storage, then decryption" cannot be tampered with.

[0087] The core concept of this invention is to introduce a “Cryptographic AttestationState Machine”, which defines each key stage of cryptographic computation as a finite state. Each state transition automatically triggers the generation and on-chaining of multidimensional evidence events, forming a complete cryptographic computation evidence chain from data input to result output.

[0088] This invention overcomes the shortcomings of the prior art through the following five technological innovations: (1) State machine for secure evidence storage: The entire life cycle of secure computing is divided into a finite set of states. Each state transition automatically triggers the generation of evidence storage events, achieving full traceability (addressing shortcomings one and four). (2) Layered cryptographic evidence storage architecture: The evidence storage is divided into an operation evidence storage layer, an evidence evidence storage layer and a data evidence storage layer, which are mutually anchored through cryptographic commitments to realize a coarse-grained and fine-grained evidence storage system (addressing the third drawback). (3) Unified evidence storage framework: Provides a unified evidence storage data structure and verification interface for different computing paths such as homomorphic encryption, multi-party secure computation, and trusted execution environment (addressing the second drawback); (4) Privacy protection verification mechanism: Through technologies such as zero-knowledge proof and homomorphic commitment, the verifier can verify the integrity of the computation process without obtaining the original data (addressing the fifth drawback). (5) Verifiable delayed evidence storage: A verifiable delayed function is introduced to realize evidence storage capability in the time dimension (addressing the sixth drawback).

[0089] I. System Architecture The system described in this invention consists of the following layers: (a) Blockchain layer The blockchain layer is the infrastructure layer of this invention, comprising a blockchain network, consensus nodes, and block data structure. The block header contains the attestation root hash, and the block body contains attestation transactions. Each attestation transaction records one attestation event of a state transition.

[0090] (ii) State Machine Layer for Closed-State Evidence Storage The encrypted evidence storage state machine layer is the core layer of this invention, deployed on the blockchain and implemented in the form of smart contracts. This layer includes the following sub-modules: State definition module: Defines the finite set of states S = {S0, S1, S2,..., S} for the entire lifetime of dense-state computation. n}

[0091] State transition engine: Defines state transition rules T(S) i →S j The system verifies whether the conversion conditions are met, and automatically triggers the generation of a certificate of authenticity event upon successful conversion.

[0092] State storage module: Stores the current state and state history records on the blockchain.

[0093] (III) Evidence Generation Layer The evidence generation layer is deployed on the computing nodes of each participating party and works in conjunction with the dense computing engine. This layer contains the following sub-modules: Operation Evidence Generation Module: Generates operation evidence for each encrypted operation, including operation type, operation time, and participant identity verification (based on group signature to protect identity privacy).

[0094] Computational Evidence Generation Module: Generates zero-knowledge proofs of the correctness of each dense-state computation.

[0095] Linked Evidence Generation Module: Generates cryptographic pointers to the previous and subsequent states to ensure chainable verification of state transitions.

[0096] (iv) Adaptive computation routing layer The adaptive computation routing layer dynamically selects the optimal dense computation path based on the characteristic parameters of the computation task (data type, computational complexity, privacy level, performance requirements, etc.). Lightweight linear computation → Homomorphic encryption path Multi-party collaborative nonlinear computation → Multi-party secure computation path High-performance intensive computing → Trusted execution environment path Different computing paths share a unified evidence storage interface to ensure consistency in evidence storage formats.

[0097] (v) Layered Evidence Storage Layer The layered evidence storage layer divides the evidence data into three levels: The three layers are mutually anchored through cryptographic commitments: L1 evidence storage includes the hash commitment of L2 evidence storage, and L2 evidence storage includes the hash commitment of L3 evidence storage, forming an evidence storage system that is "verifiable on-chain and reproducible off-chain".

[0098] (vi) Verification and Audit Layer The verification and audit layer provides a unified verification interface for external auditors, regulators, and data users. Integrity verification: Verify the integrity and continuity of the state transition sequence. Correctness verification: Verify the zero-knowledge proof and confirm the correctness of the dense-state calculation results. Compliance verification: Verify whether the operations of each participating party comply with the preset compliance rules. Privacy-preserving audit: The auditor uses zero-knowledge proofs to demonstrate audit authority to the blockchain. Once the authority verification is successful, the auditor can obtain the metadata of the stored evidence, but the original encrypted data remains invisible. (a) Definition of Evidence Preservation Status This invention defines the following finite set of states: S0: Initialization state – System deployment complete, awaiting computation tasks. S1: Key Ready Status – Participants have completed generating key materials. S2: Data densification state – The original data has been densified. S3: State during dense state computation – Dense state computation task is in progress. S4: Stage Completion Status – Dense state calculation for a certain stage has been completed. S5: Computation Completion Status – All dense state calculation tasks completed. S6: Verification Passed Status – Evidence verification passed S7: Decryption ready state – Decryption conditions are met, decryption can be performed. (ii) Data structure of evidence storage events Each evidence storage event E contains the following fields: E = {event_id: globally unique event identifier, state_from: identifier of the preceding state. state_to: Current state identifier, sequence_number: Global state sequence number. operation_type: Operation type (encryption / homomorphic addition / homomorphic multiplication / MPC computation / decryption, etc.) Participants: A set of participant identifiers (protected by group signature). input_commitment: The cryptographic commitment to the input data. output_commitment: The cryptographic commitment to the output data. zk_proof: Zero-knowledge proof of computational correctness. prev_hash: A hash pointer to the preceding evidence-gathering event. Timestamp: Operation timestamp, vdf_proof: Verifiable proof of the delayed function (optional) (III) Data Structure for Evidence Storage Aggregation To reduce on-chain storage overhead, multiple consecutive state transition evidence events are aggregated into a Merkle tree, and the Merkle root is uploaded to the chain: AttestationBlock = { block_height: evidence block height, merkle_root: root hash of the evidence event Merkle tree, event_count: number of aggregated evidence events, prev_block_hash: hash pointer of the previous evidence block, timestamp: evidence block generation time}.

[0099] like Figure 2 As shown, it mainly consists of the following 6 core parts: Blockchain layer: As the underlying trust infrastructure, it is responsible for storing the root hash of the evidence and executing the evidence transaction.

[0100] Secure State Machine (CASM): The core logic component, existing in the form of smart contracts, is responsible for state management and transitions.

[0101] Evidence generation layer: Deployed on computing nodes, responsible for generating operational evidence, zero-knowledge proofs (ZKP), and related evidence.

[0102] Adaptive computation routing layer: responsible for selecting the optimal computation path (HE / MPC / TEE) based on task characteristics.

[0103] Layered evidence storage layer: responsible for the classified storage of three layers of data (L1 / L2 on the blockchain, L3 in distributed storage).

[0104] Verification and Audit Layer: Provides external interfaces for auditors, regulators, and data users to perform compliance verification.

[0105] Relationship between instructions and data flow: The verification and auditing layer sends requests to the state machine layer through an interface; the routing layer invokes different computation paths of the evidence generation layer according to the instructions.

[0106] Evidence storage anchoring relationship (core connection): The original evidence generated by the evidence generation layer is stored in the storage layer to generate L3 hash; the L3 hash is embedded as a parameter into the L2 evidence, and the hash of the L2 evidence is finally embedded into the L1 state transition event and submitted to the blockchain layer through the state machine layer.

[0107] State triggering relationship: Each time a computing node completes a dense state operation.

[0108] like Figure 3 The diagram shows the state transitions of the dense-state evidence storage state machine.

[0109] like Figure 4 As shown, L1 is the operation storage layer (state identifier, sequence number, timestamp, etc.), L2 is the evidence storage layer (ZKP proof, homomorphic commitment, etc.), L3 is the data storage layer (ciphertext fragmentation, metadata, etc.), and the cryptographic commitment pointer (connector component).

[0110] Beneficial effects: This invention, through a complete "dynamic encrypted evidence storage engine" system, resolves the structural contradiction between the privacy protection requirement of "hiding" and the evidence storage verification requirement of "openness" in existing technologies, and realizes the traceability, verifiability and auditability of the entire life cycle of encrypted computing.

[0111] This invention enables full traceability of the encrypted computation process. Through an encrypted evidence storage state machine, each state transition automatically generates an evidence storage event and uploads it to the blockchain. Each state is sequentially linked through cryptographic pointers, allowing any encrypted computation result to be traced back to the data input along the state sequence, thus achieving "results that can be checked and processes that can be traced".

[0112] This invention achieves a balance between privacy protection and verifiability. Through a layered evidence storage architecture (L1 operation layer → L2 evidence layer → L3 data layer) and inter-layer cryptographic commitment anchoring, the verifier can verify the correctness of the computation only through zero-knowledge proofs of L1 and L2, without needing to access the L3 ciphertext data, thus achieving "verifiable but invisible".

[0113] This invention enables unified evidence storage across multiple dense computation paths. By employing adaptive computation routing, it provides a unified evidence storage data structure and verification interface for different paths, achieving unified auditing across paths.

[0114] It possesses reliable evidence storage capabilities in the time dimension. This invention combines a verifiable delay function (VDF) with evidence storage. After the encrypted calculation is completed, a VDF proof is generated and uploaded to the blockchain. Decryption can only be performed after the delay period expires, ensuring that the time order of "evidence storage first, decryption later" cannot be tampered with, providing a reliable time anchor for scenarios such as timed decryption and delayed auditing.

[0115] On-chain storage has low overhead and strong engineering feasibility. This invention aggregates evidence-keeping events of continuous state transitions into a Merkle tree and only puts the root on the chain, significantly reducing storage costs while ensuring verifiability.

[0116] The above specific embodiments further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A blockchain privacy computing method based on a dynamic encrypted evidence storage engine, characterized in that, The calculation method includes: Step S1: Initialization and state machine deployment; Step S2: Publish computation task and negotiate key; Step S3: Data encryption and layered evidence storage; Step S4: Execution of dense-state computation and state-by-state evidence storage; Step S5: Evidence aggregation and batch on-chain storage; Step S6: Verification of evidence; Step S7: Verify decryption and final evidence storage.

2. The blockchain privacy computing method based on a dynamic encrypted evidence storage engine according to claim 1, characterized in that, Step S1: Initialization and State Machine Deployment specifically includes: Step S1.1: Deploy the secure state machine smart contract on the blockchain network, and define the state set S and the state transition rule T; Step S1.2: Each participant registers their identity in the system and generates their own key materials. The participants include data providers, data users, computing nodes, and auditors. Step S1.3: The state machine enters the initialization state S0, generates the initial evidence storage event E0, and uploads it to the chain.

3. The blockchain privacy computing method based on a dynamic encrypted evidence storage engine according to claim 1, characterized in that, Step S2: Computation task release and key negotiation specifically includes: Step S2.1: The data user publishes a cryptographic computation task through a smart contract, specifying the computation function, participant requirements, and privacy level; Step S2.2: Each participant completes key negotiation according to the task requirements, including the generation of homomorphic encryption public and private keys and the generation of MPC secret sharing shares; Step S2.3: After the key is ready, the state machine transitions from S0 to S1, generating a notarization event E1 and uploading it to the chain; notarization event E1 contains the cryptographic commitment of the public keys of each participating party.

4. The blockchain privacy computing method based on a dynamic encrypted evidence storage engine according to claim 1, characterized in that, Step S3: Data encryption and layered evidence storage specifically includes: Step S3.1: The data provider performs densification processing on the raw data according to the selected computation path. If a homomorphic encryption path is selected, the data will be encrypted using a homomorphic encryption algorithm; If the MPC path is selected, the data will be fragmented using a secret sharing protocol; If the TEE path is selected, the data will be loaded within the Trusted Execution Environment; Step S3.2: Calculate the cryptographic commitment of the ciphertext data, store the ciphertext data in an off-chain distributed storage network, and submit the commitment value to the blockchain; Step S3.3: The state machine transitions from S1 to S2, generating a storage event E2 and uploading it to the blockchain; the storage event E2 includes: a cryptographic commitment to the encrypted data, a zero-knowledge proof of the encryption operation, and the identity evidence of the data provider.

5. A blockchain privacy computing method based on a dynamic encrypted evidence storage engine according to claim 1, characterized in that, Step S4: Dense-state computation execution and state-by-state evidence storage specifically includes: Step S4.1: The smart contract selects the optimal computation path based on the computation task parameters; Step S4.2: Perform dense-state computation along the selected computation path. After each dense-state operation is completed, the state machine performs a state transition. Step S4.3: Each state transition automatically triggers the generation of a notarization event. The notarization event includes: the current state identifier and the global state sequence number, the operation type identifier, the participant identifier, the cryptographic commitment of the computation input, the cryptographic commitment of the computation output, the zero-knowledge proof of the computation correctness, and the hash pointer of the notarization event of the previous state. Step S4.4: The state machine sequentially undergoes multiple transitions, including the dense state calculation S3 and the phased completion S4. Each transition generates a corresponding evidence storage event and uploads it to the blockchain. Step S4.5: After all the dense state calculation tasks are completed, the state machine transitions to the calculation completion S5 and generates the evidence storage event E_complete.

6. A blockchain privacy computing method based on a dynamic encrypted evidence storage engine according to claim 1, characterized in that, Step S5: Evidence aggregation and batch on-chain storage specifically includes: Step S5.1: The evidence generation layer aggregates multiple consecutive evidence-preserving events into a Merkle tree; Step S5.2: Calculate the Merkle root hash, and submit the Merkle root and the Merkle path of each evidence storage event as evidence storage transactions to the blockchain; Step S5.3: The blockchain packages the evidence storage transaction into a block, and writes the evidence storage root hash into the block header; Step S5.4: The original evidence event data is stored off-chain, and the existence of a specific evidence event is verified when needed via the Merkle path.

7. A blockchain privacy computing method based on a dynamic encrypted evidence storage engine according to claim 1, characterized in that, Step S6: Evidence verification specifically includes: Step S6.1 The verifier obtains the root hash of the evidence storage block from the blockchain; Step S6.2 The verifier obtains the evidence storage event data and Merkle path to be verified from off-chain; Step S6.3 The verifier performs verification in the following manner: After all verifications are passed in step S6.4, the state machine transitions to Verification Pass S6, generating the evidence storage event E_verify.

8. A blockchain privacy computing method based on a dynamic encrypted evidence storage engine according to claim 7, characterized in that, The verification process in step S6.3 specifically includes the following methods: The Merkle path was used to verify that the evidence storage event was indeed included in the evidence storage block; Verify the continuity and integrity of the state transition sequence using the preceding hash pointer; The correctness of each dense-state calculation is verified using zero-knowledge proofs; Verify the consistency of input and output data using commitment values.

9. A blockchain privacy computing method based on a dynamic encrypted evidence storage engine according to claim 1, characterized in that, Step S7: Verifiable decryption and final evidence storage specifically includes: Step S7.1: Determine whether the preset decryption conditions are met, including the end of the time delay, multi-party authorization, and compliance review approval; Step S7.2: If a time delay requirement is involved, the verifier can verify the delay function proof and confirm that the decryption time meets the preset conditions; Step S7.3: Perform the decryption operation. The decryption process is also recorded as a state transition. Step S7.4: The state machine transitions to decryption ready S7, generating the final evidence storage event E_final, forming a complete encrypted computation evidence storage chain from S0 to S7.

10. A blockchain privacy computing system based on a dynamic encrypted evidence storage engine, employing the blockchain privacy computing method based on a dynamic encrypted evidence storage engine as described in any one of claims 1-9, characterized in that, The computing system includes: The initialization and deployment module is used for initialization and state machine deployment; The adaptive routing module is used for computation task publishing and key negotiation; The layered evidence storage module is used for data encryption and layered evidence storage; The state machine module for dense-state evidence storage is used for dense-state computation execution and state-by-state evidence storage. The evidence generation module is used for evidence aggregation and batch on-chain storage; The verification module is used for evidence verification. The decryption module is used for verifiable decryption and final evidence storage.

Images