Blockchain-based supply chain data sharing method and system

Abstract

The application relates to the technical field of blockchain and supply chain data security, and discloses a supply chain data sharing method and system based on a blockchain, which has the technical scheme as follows: based on a consortium chain network, attribute encryption parameters and main private key fragments are generated by a distributed attribute authority, and an operating environment is obtained by initialization in a trusted execution environment; after being double-encrypted and encapsulated by an access strategy, being registered on a chain, and being decrypted in the trusted execution environment, controlled plaintext and a closed activation registration record are obtained; a proof set is obtained by a revocation transaction, overwritten erasure and non-interactive zero-knowledge proof; a compliance audit conclusion is obtained by recursive knowledge demonstration aggregation and zero-knowledge verification. The application constructs a data security protection system for the whole life cycle of supply chain data sharing based on a consortium chain network and a trusted execution environment, through a distributed attribute authority, double-encrypted encapsulation and recursive zero-knowledge aggregation, and solves the problems of insufficient security, controllability and compliance in cross-subject data sharing.

Description

Technical Field

[0001] This invention relates to the field of blockchain and supply chain data security technology, specifically to a blockchain-based supply chain data sharing method and system. Background Technology

[0002] Currently, the digital economy and IoT technology are deeply integrated, accelerating the digital transformation of the entire supply chain. Cross-entity data sharing has become a core support for improving supply chain collaboration efficiency and enhancing industrial chain resilience. However, with numerous participants and complex business processes in the supply chain, data faces security challenges during collection, transmission, storage, and sharing. Traditional centralized data sharing platforms suffer from high single-point-of-failure risks, data susceptibility to tampering, and a lack of transparency in the sharing process, making it difficult to meet the trust and security requirements of a multi-entity collaborative supply chain environment. Blockchain technology, with its decentralized, immutable, and traceable characteristics, has seen initial applications in areas such as supply chain traceability. However, existing blockchain-based supply chain data sharing solutions still have shortcomings in balancing fine-grained access control, key lifecycle management, compliance auditing, and privacy protection. They struggle to simultaneously ensure the security, controllability, and compliance of data sharing, and cannot effectively address the multi-dimensional security challenges in complex supply chain scenarios. Therefore, existing technologies have limitations. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention aims to provide a blockchain-based supply chain data sharing method and system. It generates attribute encryption parameters and master private key fragments through distributed attribute authority generation and initializes the runtime environment in a trusted execution environment. Based on the runtime environment, after double-layer encryption encapsulation using access policies and on-chain registration, it is decrypted in the trusted execution environment to obtain controlled plaintext and closure activation registration records. A proof set is obtained based on transaction revocation, overwrite erasure, and non-interactive zero-knowledge proofs. Compliance audit conclusions are obtained through recursive knowledge argument aggregation and zero-knowledge verification. This achieves the organic unity of fine-grained access control, mandatory key destruction, and privacy-preserving auditing in supply chain data sharing, constructing a closed-loop data security system covering the entire chain from data generation, transmission, use to destruction. It solves the shortcomings of existing technologies, such as coarse-grained access control, lack of mandatory key retrieval guarantees, the conflict between compliance auditing and privacy protection, and single-point security risks. This improves the data security protection level, controllability, and compliance auditing efficiency throughout the entire lifecycle of supply chain data sharing.

[0004] To achieve the above objectives, the present invention adopts the following technical solution:

[0005] In a first aspect, the present invention provides a blockchain-based supply chain data sharing method, comprising:

[0006] Based on the consortium blockchain network, attribute encryption parameters and master private key fragments are generated through distributed attribute authority, and the runtime environment is obtained by initialization in a trusted execution environment.

[0007] Based on the aforementioned operating environment, after double-layer encryption and on-chain registration of the access policy, the controlled plaintext and closure activation registration record are obtained by decryption in the trusted execution environment.

[0008] Based on the controlled plaintext and closure activation registration record, a set of proofs is obtained through transaction revocation, overwrite erasure, and non-interactive zero-knowledge proof.

[0009] Based on the aforementioned set of proofs, compliance audit conclusions are obtained through recursive knowledge argument aggregation and zero-knowledge verification.

[0010] Furthermore, the process of generating attribute encryption parameters and master private key shards based on a consortium blockchain network through a distributed attribute authority, and initializing them in a trusted execution environment to obtain the runtime environment, includes:

[0011] Based on supply chain needs, a consortium blockchain network is obtained by deploying a practical Byzantine fault-tolerant consensus protocol and dividing business isolation channels.

[0012] Based on the aforementioned consortium blockchain network, the attribute encryption parameters and master private key fragments are obtained by deploying independent attribute authorities by supply chain participants and using secure multi-party computation and collaborative operation.

[0013] Based on the aforementioned consortium blockchain network and attribute encryption parameters, an on-chain business function contract set is obtained by deploying smart contracts.

[0014] Based on the aforementioned on-chain business function contract set, the operating environment is obtained by generating blockchain identity, data symmetric key, and performing remote proof binding.

[0015] Furthermore, the step of obtaining attribute encryption parameters and master private key shards based on the consortium blockchain network by deploying independent attribute authorities among supply chain participants and conducting secure multi-party computational collaborative operations includes:

[0016] Based on the aforementioned consortium blockchain network, a distributed set of attribute authorities is obtained by deploying independent attribute authorities by supply chain participants and defining attribute namespaces and review processes.

[0017] Based on the distributed attribute authority set, attribute encryption parameters and master private key fragments are obtained by selecting random shares and inputting them into a secure multi-party computation protocol for joint operation.

[0018] Furthermore, the process of obtaining controlled plaintext and closure activation registration record by double-layer encryption encapsulation and on-chain registration based on the operating environment, followed by decryption in the trusted execution environment, includes:

[0019] Based on the operating environment and raw supply chain data, data classification and grading labels are obtained through sensitivity assessment and business domain classification.

[0020] Based on the data classification and grading labels, an access policy tree is constructed, attribute encryption based on the ciphertext policy is performed, and then the data is encapsulated to obtain the ciphertext and closure object.

[0021] Based on the encrypted data and the closure object, the registration record and controlled plaintext are obtained through on-chain registration index, attribute decryption and controlled output;

[0022] Based on the controlled plaintext, a closure activation registration record is obtained by generating a hardware-signed remote proof report and submitting it to the self-destruct proof contract via an anonymous transaction.

[0023] Furthermore, based on the data classification and grading labels, the process involves constructing an access policy tree, performing attribute encryption based on a ciphertext policy, and then encapsulating the data to obtain ciphertext and a closure object, including:

[0024] Based on the data classification and hierarchical labels, an access strategy tree is constructed according to the attribute namespace;

[0025] Based on the aforementioned symmetric key, the plaintext is encrypted using the AES-256-GCM algorithm, and an authentication tag is generated to obtain the ciphertext.

[0026] Based on the access policy tree and the data symmetric key, the data symmetric key is encrypted by calling the attribute encryption algorithm based on the ciphertext policy to obtain the key ciphertext;

[0027] Based on the key ciphertext, the internal components of the closure are obtained by calculating the integrity hash of the decryption logic and the self-destruction logic and generating an anonymous identifier, and then packaged with a digital signature to obtain the closure object.

[0028] Furthermore, the set of proofs obtained based on the controlled plaintext and closure activation registration record through transaction revocation, overwrite erasure, and non-interactive zero-knowledge proofs includes:

[0029] Based on the controlled plaintext and closure activation registration record, the affected closure is marked by the self-destruct proof contract and the revocation transaction is broadcast in a manner mixed with noise events to obtain the set of revoked anonymous identifiers and the effective timestamp;

[0030] Based on the set of revoked anonymous identifiers, self-destruction operation logs are obtained through polling detection and overwriting erasure.

[0031] Based on the self-destruction operation log, a zero-knowledge self-destruction proof of the closure object is obtained through non-interactive zero-knowledge proof, and a proof set is constructed based on the zero-knowledge self-destruction proof of the closure object.

[0032] Furthermore, the step of obtaining a zero-knowledge self-destruction proof of the closure object through non-interactive zero-knowledge proof based on the self-destruction operation log, and constructing a proof set based on the zero-knowledge self-destruction proof of the closure object, includes:

[0033] The zero-knowledge proof private input is obtained based on the erase success status code and completion timestamp in the self-destruct operation log.

[0034] Based on the private input of the zero-knowledge proof, an instance of a zero-knowledge circuit is obtained by constructing an arithmetic constraint circuit.

[0035] Based on the zero-knowledge circuit instance, a zero-knowledge self-destruct proof is obtained by executing a proof generation algorithm.

[0036] Furthermore, the process of obtaining compliance audit conclusions based on the set of proofs through recursive knowledge argument aggregation and zero-knowledge verification includes:

[0037] Based on the aforementioned set of proofs, an aggregated proof is obtained by recursively aggregating knowledge arguments using a binary tree structure.

[0038] Based on the aggregated proof, a compliance audit conclusion is obtained through zero-knowledge verification.

[0039] Furthermore, the process of obtaining aggregated proofs based on the set of proofs through recursive knowledge argument aggregation using a binary tree structure includes:

[0040] Based on the set of proofs, a sequence of proof pairs is obtained by constructing a proof merging tree;

[0041] Based on the aforementioned proof pair sequence, the layer-by-layer intermediate aggregation proof is obtained by verifying the validity of the key;

[0042] Based on the root node of the proof merging tree and the intermediate aggregation proofs layer by layer, the aggregate proof is obtained through recursive verification in the final round.

[0043] Secondly, the present invention provides a blockchain-based supply chain data sharing system, comprising:

[0044] Environment initialization module: Used to generate attribute encryption parameters and master private key fragments based on the consortium blockchain network through distributed attribute authority, and initialize the runtime environment in the trusted execution environment;

[0045] Encrypted sharing module: Based on the aforementioned operating environment, it is used to obtain controlled plaintext and closure activation registration record by double-layer encryption encapsulation through access policy and on-chain registration, followed by decryption in the trusted execution environment;

[0046] Self-destruction proof module: used to obtain a set of proofs based on the controlled plaintext and closure activation registration record by revoking transactions, overwriting and erasing, and non-interactive zero-knowledge proofs;

[0047] Aggregated Audit Module: Used to obtain compliance audit conclusions based on the set of proofs through recursive knowledge argument aggregation and zero-knowledge verification.

[0048] Compared with the prior art, the beneficial effects achieved by the present invention are as follows:

[0049] This invention utilizes a consortium blockchain network and a trusted execution environment to initialize the operating environment. It generates attribute encryption parameters and master / private key fragments through distributed attribute authority, employs a two-layer encryption encapsulation of access policies to achieve fine-grained authorized data sharing, and enforces key destruction and verifiable self-destruction through transaction revocation, overwriting, erasure, and non-interactive zero-knowledge proofs. Privacy-preserving compliance auditing is then achieved through recursive knowledge argument aggregation and zero-knowledge verification. This invention realizes attribute-based fine-grained access control, closed-loop key lifecycle management, and zero-knowledge privacy-preserving compliance auditing, constructing a data security closed loop for the entire lifecycle of supply chain data sharing. It solves the core data security problems of insufficient granularity of access control, lack of mandatory technical guarantees for key eviction, and difficulty in balancing compliance auditing and data privacy protection in traditional solutions, thus improving the security, auditability, and privacy protection level of cross-entity data sharing in the supply chain. Attached Figure Description

[0050] Figure 1 This is a flowchart illustrating the steps of the blockchain-based supply chain data sharing method of the present invention.

[0051] Figure 2 A flowchart outlining the steps to obtain the runtime environment;

[0052] Figure 3 Flowchart of steps to obtain controlled plaintext and closure activation registration record;

[0053] Figure 4 Flowchart of the steps to obtain a set of proofs through transaction reversal, overwriting / erasing, and non-interactive zero-knowledge proofs;

[0054] Figure 5 A flowchart illustrating the steps involved in obtaining compliance audit conclusions through recursive knowledge argument aggregation and zero-knowledge verification.

[0055] Figure 6 This is a schematic diagram of the blockchain-based supply chain data sharing system of the present invention. Detailed Implementation

[0056] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments of the present invention and the specific features in the embodiments are detailed descriptions of the technical solution of the present invention, rather than limitations thereof.

[0057] The term "and / or" in the following text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0058] Example 1:

[0059] like Figure 1 As shown, this embodiment provides a blockchain-based supply chain data sharing method, including:

[0060] Based on the consortium blockchain network, attribute encryption parameters and master private key fragments are generated through distributed attribute authority, and the runtime environment is obtained by initialization in a trusted execution environment.

[0061] Based on the runtime environment, after double-layer encryption and on-chain registration of the access policy, the controlled plaintext and closure activation registration record are obtained by decryption in the trusted execution environment.

[0062] Based on controlled plaintext and closure-activated registration records, a set of proofs is obtained through transaction reversal, overwrite erasure, and non-interactive zero-knowledge proofs.

[0063] Based on the proof set, compliance audit conclusions are obtained through recursive knowledge argument aggregation and zero-knowledge verification.

[0064] The consortium blockchain network is a blockchain network jointly maintained by nodes of all participants in the supply chain, built on a practical Byzantine fault-tolerant consensus protocol. It achieves data isolation between channels by dividing channels according to supply chain business domains, and channel members are managed uniformly by the consortium governance committee. The distributed attribute authority is an independent attribute key management server deployed within the security domains of each core participant. It defines attribute namespaces for its subordinate organizations, reviews user attribute applications, and issues attribute private keys. Each attribute authority collaboratively generates attribute encryption parameters and master private key shards through a secure multi-party computation protocol. The attribute encryption parameters are globally common parameters used by attribute encryption algorithms based on ciphertext policies. They are obtained by each attribute authority selecting random shares and inputting them into the secure multi-party computation protocol for joint computation. These parameters include a bilinear group and its generator, a bilinear mapping, and group elements obtained by aggregating the shares. The master private key shards are based on threshold secrets. The sharing scheme divides the master private key into key fragments held by various attribute authorities. The master private key is obtained by aggregating random shares selected by each attribute authority through secure multi-party computation. The master private key can be recovered by any number of attribute authorities that meet or exceed a threshold number; otherwise, no valid information can be obtained. The trusted execution environment is a secure, isolated execution area built on hardware security extensions, used to provide tamper-proof operating boundaries for the generation, decryption, execution, and self-destruction of auditable key closures. Initialization is the process by which the trusted execution environment executes a remote proof process upon first activation, generating a hardware-signed remote proof report containing enclave code and initial state metrics, and submitting it to the controlled self-destruct proof contract of the trusted execution environment for verification and binding registration. The runtime environment is a ready system state containing the on-chain identity identifiers of the participants, data symmetric keys, trusted execution environment enclave metrics, and associated configurations with the on-chain business function contract set.

[0065] The access policy employs a two-layer encryption method, combining symmetric encryption of the plaintext data body with attribute encryption based on a ciphertext policy for the symmetric key. This method enables fine-grained access control based on attributes and ensures that key materials are invisible to users. Encapsulation involves packaging the key ciphertext, the self-destruct proof contract address, the upper bound of the attribute validity period, the anonymous identifier, and the integrity hash value within a trusted execution environment and then digitally signing them. On-chain registration involves writing the data ciphertext, the content addressing identifier of the closure object, and related index information into the consortium blockchain state database by calling a data registration contract. Controlled plaintext refers to the data content processed by a controlled output policy after attribute decryption and integrity verification are completed within the trusted execution environment sandbox, based on data classification and grading labels. Closure activation registration record is a record generated by the trusted execution environment enclave with a hardware signature after the auditable key closure is successfully decrypted for the first time within the requester's trusted execution environment. This record is submitted to the self-destruct proof contract via an anonymous transaction and, after contract verification, is written into the valid witness mapping table.

[0066] The revocation transaction is an on-chain transaction that changes the status of the corresponding closure anonymous identifier to "revoked" and carries a revocation effective timestamp, based on the expiration of the attribute validity period or the attribute authority's active revocation instruction, according to the self-destruction proof contract. Overwrite erasure involves performing multiple secure erasure operations with different byte patterns on the key ciphertext cache and symmetric key plaintext cache within the secure zone of the trusted execution environment to ensure the irreversible destruction of key materials. The non-interactive zero-knowledge proof is a cryptographic proof generated using Groth16 concise non-interactive zero-knowledge argument, used to prove that the closure instance has completed the self-destruction operation without revealing execution details. It is obtained by constructing an arithmetic constraint circuit and executing a proof generation algorithm, using the erase success status code and completion timestamp in the self-destruction operation log as secret witnesses. The set consists of a collection of zero-knowledge self-destruct proofs independently generated and temporarily stored by all affected clients; the recursive knowledge proof aggregation is the process of merging and verifying multiple zero-knowledge self-destruct proofs layer by layer using a binary tree structure and compressing them into a single aggregate proof, which is completed by the off-chain aggregation module calling the recursive validator; zero-knowledge verification is the process of executing a single verification algorithm on the aggregate proof using the verification key generated during the system initialization phase, used to confirm that all self-destruct operations covered by the aggregate proof have been completed; the compliance audit conclusion is a structured record generated based on the zero-knowledge verification results, containing an audit timestamp, revocation batch number, number of affected closure instances, and verification pass status, which is used for alliance members to view without disclosing the data content, storage location, and visitor identity information.

[0067] This embodiment achieves trusted sharing of supply chain data among multiple parties within a secure isolation boundary by constructing a consortium blockchain network based on practical Byzantine fault-tolerant consensus and dividing it into isolated channels according to business domains. By deploying distributed attribute authorities and collaboratively generating attribute encryption parameters and master private key threshold sharding based on ciphertext policies through secure multi-party computation, it eliminates single-point key escrow risks and constructs a decentralized data security key management system. Through a two-layer encryption mechanism combining symmetric encryption and attribute encryption based on ciphertext policies, and encapsulating the key ciphertext into an auditable key closure bound by integrity hashes, it achieves fine-grained access control of key materials that are invisible and unextractable to users, reducing the risk of data security leakage at the source. Through trusted execution environment hardware signature remote proof and anonymous transaction registration mechanisms, it achieves verifiability of the closure activation state without revealing the visitor's identity, strengthening data security. Data security and privacy protection during use; by forcibly overwriting and erasing key materials multiple times with non-maskable interruptions within a trusted execution environment, and generating non-interactive zero-knowledge self-destruction proofs using local self-destruct logs as secret witnesses, the verifiability of self-destruction facts is achieved without exposing execution details, thus improving data security in the data destruction process; by recursively verifying and aggregating zero-knowledge self-destruction proofs into a single aggregate proof using a binary tree structure, the audit verification overhead is independent of the number of original proofs, achieving lightweight compliance auditing; by enabling regulatory agencies to confirm that all affected instances have lost their decryption capabilities with only a single zero-knowledge verification of the aggregate proof, compliance auditing can be completed without disclosing data content, storage location, and visitor identity information, thereby enhancing the data security protection capabilities, auditability, and privacy protection level throughout the entire lifecycle of supply chain data sharing.

[0068] Furthermore, this embodiment provides a step-by-step approach based on a consortium blockchain network, which involves generating attribute encryption parameters and master private key shards through a distributed attribute authority, and initializing them in a trusted execution environment to obtain the runtime environment. The steps include:

[0069] Based on supply chain needs, a consortium blockchain network is obtained by deploying a practical Byzantine fault-tolerant consensus protocol and dividing business isolation channels.

[0070] Based on a consortium blockchain network, attribute encryption parameters and master private key fragments are obtained through secure multi-party computation and collaborative operations by deploying independent attribute authorities among supply chain participants; specifically including:

[0071] Based on the consortium blockchain network, a distributed set of attribute authorities is obtained by deploying independent attribute authorities by supply chain participants and defining attribute namespaces and review processes; based on the distributed set of attribute authorities, attribute encryption parameters and master private key shards are obtained by selecting random shares and inputting them into a secure multi-party computation protocol for joint computation.

[0072] Based on the consortium blockchain network and attribute encryption parameters, a set of on-chain business function contracts is obtained by deploying smart contracts.

[0073] Based on the on-chain business function contract set, the operating environment is obtained by generating blockchain identity, data symmetric key and remotely verifying binding.

[0074] The supply chain requirements are defined by the business scenarios, security requirements, and industry compliance standards of full-chain data sharing within the supply chain. These requirements were determined through joint research, demand analysis, and review by the alliance governance committee and participating parties. The Practical Byzantine Fault-Tolerant Consensus Protocol (PBTCP) is a consensus algorithm that ensures the consistency of ledger data across nodes in a distributed system with malicious nodes. It guarantees the reliable execution of transactions and the immutability of the ledger in the consortium blockchain network. Its core parameters include view switching timeout, checkpoint generation cycle, and the maximum tolerated Byzantine nodes, typically rounded down to one-third of the total number of nodes. Dividing the network into business isolation channels involves dividing the consortium blockchain network into multiple independent logical sub-networks based on different business domains within the supply chain. This achieves physical isolation of data across different business domains, ensuring that transaction data within a channel is only visible to authorized nodes that have joined that channel, and that ledger data between channels is completely isolated. The consortium blockchain network is a distributed ledger network built on the PBTCP and jointly maintained by all participating nodes in the supply chain. Data isolation between channels is achieved by dividing channels according to supply chain business domains. Supply chain participants are the core entities involved in all business activities across the supply chain, including manufacturers, logistics providers, distributors, retailers, third-party quality inspection agencies, and industry regulatory bodies. Independent attribute authorities are independent attribute key management servers deployed within the security domains of each core participant. They are used to define attribute namespaces for their respective organizations, review user attribute applications, and issue attribute private keys. Attribute authorities collaborate to generate attribute encryption parameters and master private key fragments through a secure multi-party computation protocol.

[0075] The attribute namespace is a hierarchical attribute identification system using organizational identifiers, attribute categories, and attribute values. This system uniquely identifies various attributes across different organizations, preventing cross-organizational attribute conflicts. Examples include "Manufacturer A, Supplier Level, Tier 1" and "Logistics Provider B, Region, East China." The review process is a standardized attribute application processing flow that includes application material submission, qualification verification, and approval time requirements. This ensures the authenticity and validity of user attributes, with an approval time typically set at 2 business days. The distributed attribute authority set is a collection of independent attribute authorities deployed by all core participants in the supply chain. The random share is a random value independently selected by each independent attribute authority for participation in secure multi-party computation, drawn from a finite domain. ,in The large prime number is determined by security parameters. The secure multi-party computation protocol is a multi-party collaborative computation protocol based on secret sharing and obfuscated circuit technology. It is used to complete joint computations without revealing the private inputs of each participant, generating attribute encryption parameters and master private key fragments. Attribute encryption parameters are globally common parameters used by attribute encryption algorithms based on ciphertext policies. They are obtained by each attribute authority selecting random shares and inputting them into the secure multi-party computation protocol for joint computation. These parameters include a bilinear group and its generator, a bilinear mapping, and group elements obtained by aggregating the shares. Master private key fragments are key segments of the master private key, divided according to a threshold secret sharing scheme and held by each attribute authority. The master private key is obtained by aggregating the random shares selected by each attribute authority through secure multi-party computation. Any number of attribute authorities not less than the threshold number can recover the master private key; below the threshold number, no valid information can be obtained. The threshold number ranges from [value missing in original text]. to The value is usually taken as ,in This represents the number of independent attribute authorities in the distributed attribute authority set. This indicates the rounding up operation.

[0076] Smart contracts are computer programs deployed on a consortium blockchain network that can be automatically executed according to preset logic. These include data registration contracts, authorization management contracts, self-destruction proof contracts, and noise event pool contracts. The preset logic refers to automated execution rules formulated by the supply chain consortium governance committee, conforming to supply chain business rules and data security compliance specifications. It covers data registration verification rules, authorization approval effectiveness conditions, closure revocation trigger conditions, zero-knowledge proof verification logic, and noise event generation rules. The preset logic is set up as follows: after the consortium governance committee organizes all participating parties to complete business requirement reviews and rule demonstrations, the above rules are encoded into executable contract code using a smart contract programming language. After functional testing, security auditing, and consortium multi-signature approval, the code is deployed to the consortium blockchain network. Once deployed, the logic is immutable. The data registration contract is a smart contract that provides an index record writing interface. It receives data index information submitted by the data uploader and writes it to the on-chain immutable state library. It also maintains the mapping relationship between data owners and data identifier sets for rapid authorization scope verification. The authorization management contract is a smart contract that provides an interface for access requests and owner confirmation logic calls. It handles data access authorization requests, records authorization mapping relationships, and publishes authorization status change events. The self-destruct proof contract is a smart contract that provides interfaces for writing valid witness mapping tables and destroying witness mapping tables. It stores auditable key closure activation registration records and aggregated proof records, and also has a polling query interface for clients to check closure revocation status. The noise event pool contract is a smart contract with a built-in automatic noise event filling mechanism. It automatically generates and publishes noise events at random intervals within fixed time slots when there are no actual business events, ensuring a uniform event output rate from the perspective of external observers and eliminating the possibility of statistical inferences exploited by event distribution differences. The on-chain business function contract set is a collection of smart contracts composed of the data registration contract, authorization management contract, self-destruct proof contract, and noise event pool contract, used to support the automated execution of the entire supply chain data sharing process.

[0077] The blockchain identity serves as a unique identifier for each participant within the consortium blockchain network. It is represented by the public key of an X.509 format digital certificate issued by the consortium certificate authority, while the private key is encrypted and stored by the participant within a hardware-secure key container. The data symmetric key is a symmetric encryption key used to encrypt the original supply chain data. It is generated by a hardware random number generator with cryptographically strong security, and its key length is fixed at 256 bits. Remote proof binding is the process by which the trusted execution environment performs a remote proof procedure upon initial activation. This generates a hardware-signed remote proof report containing enclave code and initial state metrics, and submits it to the self-destructing proof contract for verification and binding registration. This ensures the integrity and legitimacy of the trusted execution environment and prevents the execution of malicious code that has been tampered with. The runtime environment is a ready system state containing the participant's on-chain identity identifier, data symmetric key, trusted execution environment enclave metric value, and associated configuration with the on-chain business function contract set.

[0078] Specifically, such as Figure 2 As shown, firstly, the alliance governance committee organizes all supply chain participants to provide physical or cloud servers as node infrastructure, install the alliance blockchain node program, and configure network boot information to form an initial node set. Let the initial number of nodes be... The Alliance Governance Committee sets practical Byzantine fault-tolerant consensus protocol parameters in the genesis block, including view switching timeout. Seconds, checkpoint generation cycle Number of blocks, maximum number of Byzantine nodes tolerated This enables the network to have a stable block production capability, among which This indicates rounding down. The Alliance Certificate Authority issues X.509 format digital certificates to each node, embedding the node's organizational information and business role identifier. Inter-node communication mandates two-way authentication using Transport Layer Security (TLS) to ensure only nodes with valid digital certificates can access the network. Independent channels are defined according to supply chain business domains, including raw material traceability, logistics tracking, and quality inspection report channels. The channel member list is managed by the Alliance Governance Committee. Joining or leaving a channel requires a vote by the Alliance Governance Committee, with a voting threshold of at least two-thirds of the participating nodes. Transaction data within a channel is only visible to authorized nodes that have joined the channel, and ledger data between channels is completely isolated.

[0079] Then, each core participant in the supply chain deploys an independent attribute authority server within its security domain. Each independent attribute authority defines an attribute namespace for its subordinate organizations. The namespace strictly follows a hierarchical format of "organization identifier, attribute category, attribute value." Simultaneously, an attribute application review process is established, clearly defining the application material list, qualification verification standards, and approval time requirements. Upon approval, an attribute private key is issued to the user. All independent attribute authorities collectively form a distributed attribute authority set, denoted as . Each independent attribute authority enters the secure multi-party computation collaborative operation phase. ( Independently select random numbers and , ,in It is a 256-bit large prime number. All independent attribute authorities will assign their respective random shares. and The input is a secure multi-party computation protocol based on secret sharing and obfuscated circuit technology. After multiple rounds of interactive computation, the output is attribute encryption parameters. and the master private key The calculation formula for the above parameters is based on the fundamental construction of ciphertext policy attribute encryption, specifically as follows: , ;in For prime numbers of order 1 bilinear group, for generator, It is a bilinear mapping. To and Bilinear groups of the same order This represents the total number of independent attribute authorities in the distributed attribute authority set. For the master private key component The generated bilinear group public key element, for The corresponding inverse group elements are all bilinear groups. The group elements in the group together constitute the core components of the global public key for attribute encryption, which is used for key encapsulation and policy embedding in attribute encryption. For the first Each independent attribute authority independently selects a random number share during the secure multi-party computation phase, which is known only to itself. The values ​​all come from a finite field. ; The 256-bit prime number pre-defined for the system is a finite field. The order; In a finite field Perform modulo operation on top. Indicates all Each independent attribute authority selects its own share of random numbers. In a finite field The summation operation is performed on the above to obtain the first core component of the master private key of the global attribute encryption system. ; For the first Each independent attribute authority independently selects a separate set of random number shares during the secure multi-party computation phase, which is known only to itself. The values ​​of also come from the finite field. ; Indicates all Each independent attribute authority selects its own share of random numbers. In a finite field The summation operation is performed on the above to obtain the second core component of the global attribute encryption system master private key. Master private key use Threshold secret sharing scheme is obtained by fragmentation Private key sharding ( ), where the threshold value Each master private key fragment is encrypted and stored by its corresponding independent attribute authority using the AES-256 algorithm. A joint effort of independent authoritative entities can recover the complete master private key. lower than Otherwise, no useful information can be obtained. Finally, the attribute encryption parameters are... The attribute private key is publicly available in the genesis block of the consortium blockchain, accessible to all participants. Each independent attribute authority deploys an attribute private key generation and verification contract on the chain. The contract provides a unified attribute private key generation interface. When a user applies for an attribute private key, the independent attribute authority to which the user belongs reviews the user's attribute set, calls the key generation algorithm to collaboratively generate the attribute private key bound to the attribute set, and sends it to the user via a secure channel through a two-way transport layer security protocol. The data owner does not handle any attribute private key materials throughout the entire process.

[0080] Then, smart contracts are deployed to obtain the on-chain business function contract set. Four types of smart contracts are deployed sequentially on the consortium blockchain network. All contracts pass functional, security, and performance tests on the joint testnet before being submitted to the consortium governance committee for voting and approval. The approval threshold is more than 2 / 3 of the participating voting nodes. The smart contracts are deployed sequentially to the consortium blockchain network, including: a data registration contract, which provides an interface for writing index records. The index record contains a data identifier, data file name, data type encoding, data ciphertext hash value, ciphertext Uniform Resource Identifier, encryption algorithm identifier, and data source account identifier. The contract also maintains the mapping relationship between data owners and the set of data identifiers; and an authorization management contract, which provides an interface for calling access request and owner confirmation logic. After the requester submits an authorization request transaction, the contract generates a pending authorization event and notifies the data owner through the event bus. After the data owner reviews and calls the confirmation interface, the contract writes the authorization mapping record between the data identifier and the requester's public key into the on-chain state data. The system includes a library that records both the authorization effective time and the authorization expiration time; a self-destruction proof contract is deployed, providing two types of write interfaces: a valid witness mapping table and a destroyed witness mapping table. The valid witness mapping table stores auditable key closure activation registration records, while the destroyed witness mapping table stores aggregated proof records. The contract also has a polling query interface, allowing clients to check the closure revocation status at preset intervals; a noise event pool contract is deployed, with a built-in automatic noise event filling mechanism. The fixed time slot length is set to 10 seconds. If no actual business event occurs within the fixed time slot length, the contract automatically generates and publishes noise events at random intervals, with the random interval ranging from 1 to 3 seconds, ensuring a uniform event output rate from the perspective of external observers. After all smart contracts are deployed, the on-chain address identifier and calling interface specifications of each contract are recorded. All contracts together form an on-chain business function contract set.

[0081] Finally, each participant generates a local public-private key pair within the hardware security key container. private key Stored using AES-256 encryption algorithm, export prohibited, public key. An application for an X.509 format digital certificate is submitted to the consortium's certificate authority. Once issued, the certificate serves as the participant's blockchain identity and is registered in the consortium's identity directory. Each data owner uses a hardware random number generator with cryptographically strong security to generate a 256-bit symmetric key. Key materials are temporarily stored only in secure memory and are prohibited from being written to non-volatile storage media. They are subsequently used for symmetric encryption of the original supply chain data. Each participant deploys a trusted execution environment on its local hardware platform, using a hardware security zone based on the AMDSEV-SNP scheme. After deployment, an initial remote proof process is executed: the trusted execution environment enclave generates a remote proof report containing its own code and initial state metrics. The remote proof report is signed with the hardware root key to ensure it is unforgeable; the remote proof report is submitted to a self-destructing proof contract for verification. The self-destructing proof contract verifies the validity of the report signature and the legality of the enclave metric, and then... The participant's blockchain identity is bound and registered, and recorded in the on-chain state database. Finally, the participant's blockchain identity and data symmetric key are linked. Trusted Execution Environment Enclave Metrics By associating and configuring the addresses of each contract in the on-chain business function contract set, a ready-to-run environment is formed, which can support the entire process of subsequent data encryption, sharing, and auditing. In this embodiment, parameters such as threshold values ​​and fixed time slot lengths are merely examples; those skilled in the art can set them according to actual conditions, and this embodiment does not impose any limitations on them.

[0082] This embodiment achieves trusted sharing of supply chain data within secure isolation boundaries by deploying a consortium blockchain network based on a practical Byzantine fault-tolerant consensus protocol and dividing it into isolated channels according to business domains. This ensures clear and controllable access boundaries for data from different business domains. By deploying distributed attribute authorities and generating attribute encryption parameters and master private key threshold sharding through secure multi-party computation, the risk of single-point key escrow is eliminated, achieving decentralized attribute key management and improving the data security and reliability of the key system. By deploying an on-chain business function contract set including data registration, authorization management, self-destruct witnessing, and a noise event pool, the entire data sharing process is automated and traceable, while effectively preventing external statistical inference attacks. By generating blockchain identity and data symmetric keys and completing remote proof binding in a trusted execution environment, a hardware-level secure operating environment is constructed, providing an immutable execution boundary for subsequent data security-sensitive operations and improving the data security protection capabilities, reliability, and scalability of the supply chain data sharing system during the initialization phase.

[0083] Furthermore, this embodiment provides a step-by-step process based on the runtime environment, which involves double-layer encryption encapsulation of access policies, on-chain registration, and decryption in a trusted execution environment to obtain controlled plaintext and closure activation registration records, including:

[0084] Based on the operating environment and raw supply chain data, data classification and grading labels are obtained through sensitivity assessment and business domain categorization.

[0085] Based on data classification and hierarchical labels, an access policy tree is constructed, and after performing attribute encryption based on a ciphertext policy, the data is encapsulated to obtain ciphertext and a closure object; specifically including:

[0086] Based on data classification and hierarchical labels, an access policy tree is constructed according to the attribute namespace; based on the data symmetric key, plaintext is encrypted using the AES-256-GCM algorithm and an authentication label is generated to obtain the data ciphertext; based on the access policy tree and the data symmetric key, the data symmetric key is encrypted by calling an attribute encryption algorithm based on the ciphertext policy to obtain the key ciphertext; based on the key ciphertext, the integrity hash is calculated on the decryption logic and self-destruct logic and an anonymous identifier is generated to obtain the internal components of the closure, and the closure object is packaged using a digital signature;

[0087] Based on encrypted data and closure objects, registration records and controlled plaintext are obtained through on-chain registration index, attribute decryption, and controlled output;

[0088] Based on controlled plaintext, a closure activation registration record is obtained by generating a hardware-signed remote proof report and submitting it to the self-destruct proof contract with an anonymous transaction.

[0089] The original supply chain data comprises various structured and unstructured data generated by all participants in the supply chain during their business activities. This data is collected through the participants' business management systems, IoT data collection devices, and third-party service interfaces, covering all stages of the supply chain, including raw material procurement, manufacturing, logistics, warehousing, sales and distribution, and quality inspection. Sensitivity assessment is a process of quantitatively analyzing the risk and severity of leakage of original supply chain data based on national and industry data security standards. This is achieved by analyzing data content field by field and assessing the impact of data loss or leakage on business continuity, trade secret protection, and legal compliance. Business domain classification involves categorizing data into predefined information domains based on the supply chain business processes described by the data. This is achieved by matching data content with preset business domain feature tags. Data classification and grading tags are structured metadata tags generated by combining data sensitivity levels and business domain types, used to identify the data's security level and business attributes.

[0090] The access policy tree is a set of fine-grained access control rules expressed in a tree structure. Leaf nodes correspond to attribute values ​​defined in the distributed attribute authority set, while intermediate nodes contain three logical operation units: AND gates, OR gates, and threshold gates, used to describe the attribute combination conditions required for data access. The AES-256-GCM algorithm is a symmetric encryption algorithm with associated data authentication certified by the International Organization for Standardization (ISO). It is used for high-speed encryption of raw supply chain data and to generate integrity verification tags. Its key length is fixed at 256 bits, and its initialization vector length is fixed at 96 bits. The authentication tag is a fixed-length checksum generated during the AES-256-GCM encryption process, used to verify the integrity and authenticity of the ciphertext during transmission and storage; its length is typically 128 bits. The ciphertext is the binary data obtained by encrypting the original plaintext supply chain data using the AES-256-GCM algorithm. The attribute-based encryption algorithm, which embeds an access policy into the ciphertext, is a public-key encryption algorithm used to encrypt the symmetric key of data. It enables fine-grained access control based on attributes; only users whose attribute set satisfies the embedded access policy can decrypt and obtain the symmetric key. The key ciphertext is the binary data obtained by encrypting the symmetric key using the attribute-based encryption algorithm. The decryption logic is an executable code segment pre-compiled within a trusted execution environment (TEA) enclave, used to perform attribute decryption and symmetric decryption operations. The self-destruct logic is an executable code segment pre-compiled within the TEA enclave, used to perform irreversible erasure of the key material. The integrity hash is a fixed-length digest value obtained by performing a secure hash operation on the decryption and self-destruct logic code segments, used to verify the integrity and immutability of the code segments, and is generated using the SHA-256 algorithm. The anonymous identifier is a fixed-length substring extracted from the integrity hash value, used to uniquely identify the auditable key closure; it is 128 bits long, unrelated to the data identifier, and cannot be reverse-derived. The internal components of the closure constitute a set of core data fields that make up the auditable key closure. These include the key ciphertext, the on-chain address of the self-destruct proof contract, the upper bound of the attribute validity period, the anonymous identifier, the integrity hash value, and the trusted execution environment enclave metric value. Digital signature packaging is the process of digitally signing the entire internal component of the closure using a non-exportable signing private key built into the trusted execution environment enclave. This ensures the integrity and authenticity of the closure object's origin. The closure object is a self-contained executable binary file generated after digital signature packaging, which can be loaded, run, and decrypted within an authorized trusted execution environment.

[0091] The on-chain registration index is the operation of writing encrypted data, along with the storage address and metadata information of the closure object, into the consortium blockchain state database. This is implemented by calling the data registration contract and is used for traceable data management and authorized access control. Attribute decryption is the process of using the user-held attribute private key to decrypt the encrypted key within a trusted execution environment to recover the data's symmetric key. Controlled output is a mechanism that performs differentiated output processing on the decrypted plaintext based on data classification and grading labels, used to prevent sensitive data leakage. The registration record is an immutable index record written into the consortium blockchain state database after the data registration contract executes the on-chain registration operation. Controlled plaintext is the final data content returned to the data requester after the original plaintext data has been processed by the controlled output mechanism.

[0092] The hardware-signed remote proof report is a proof document generated by the trusted execution environment enclave, containing enclave code and runtime status metrics. It is digitally signed by the hardware root key to ensure it is unforgeable and tamper-proof. Anonymous transactions are on-chain transactions issued using temporary anonymous accounts unrelated to the requester's on-chain identity, used to conceal the requester's true identity. The self-destruct proof contract is a smart contract deployed on the consortium blockchain network to store auditable key closure activation registration records and aggregated proof records. It provides two types of write interfaces—valid witness mapping table and destroyed witness mapping table—as well as a polling query interface. The closure activation registration record is an immutable record written to the valid witness mapping table after the auditable key closure is successfully decrypted for the first time, submitted to the self-destruct proof contract via an anonymous transaction, and verified.

[0093] Specifically, such as Figure 3 As shown, the first step is to obtain the original supply chain data set to be shared. Let the original supply chain data set contain... Each data file is classified into three security levels: Level 1 (general data, minimal impact from loss or leakage); Level 2 (important data, potentially disrupting business operations or damaging trade secrets); and Level 3 (core data, potentially causing significant economic losses or compliance penalties). Based on the business processes described, the data is categorized into predefined business domains, including logistics, quality inspection, inventory, customer, and production. Data security level identifiers are combined with business domain type codes to create structured data classification and grading labels in the format "level code - business domain code," for example, "1-01" represents Level 1 logistics data, "2-02" represents Level 2 quality inspection data, and "3-03" represents Level 3 inventory data. Each data file corresponds to a unique data classification and grading label.

[0094] Then, based on the data classification and hierarchical labels of each data file, an access policy tree is constructed using the attribute namespace defined by the distributed attribute authority set. The access policy tree construction rules are as follows: Level 1 data adopts a lenient policy, requiring only that users have the attributes of registered alliance members; Level 2 data adopts a moderately strict policy, requiring users to meet specific attribute combinations; Level 3 data adopts the strictest policy, and in principle, it is not shared. If sharing is absolutely necessary, it must be approved by the data security committee, and multi-factor attribute constraints must be set. Generate a 96-bit random initialization vector. The AES-256-GCM algorithm was used to process the raw supply chain data. Encryption is performed using a calculation formula constructed based on the AES-GCM standard, specifically as follows: ;in The 256-bit symmetric key generated during the system initialization phase. The initialization vector is generated by a hardware random number generator with cryptographically strong security measures. For raw supply chain data, To add authentication data, retrieve the data identifier. The binary representation of To encrypt the generated ciphertext, A 128-bit authentication tag is used to verify the integrity of the encrypted data. This is an AES-256-GCM symmetric encryption algorithm with associated data authentication. It calls an attribute encryption algorithm based on a ciphertext policy to encrypt the symmetric key on the data. Encryption is performed, and the calculation formula is constructed based on the ciphertext policy attributes. Specifically: ;in The attribute encryption parameters generated and written to the genesis block during the system initialization phase. For data symmetric keys, For the constructed access policy tree, To encrypt the generated key ciphertext, This is an attribute-based encryption algorithm based on ciphertext policies, used to embed access policies into ciphertext to achieve fine-grained access control. Within a trusted execution environment's secure zone, it decrypts the logic code segment. With self-destruct logic code segment Perform a SHA-256 hash operation to obtain the integrity hash value. ,in SHA-2 is a 256-bit secure hash algorithm used to generate fixed-length irreversible hashes. This involves byte concatenation, first concatenating the binary contents of two code segments, then performing a hash operation on the concatenated whole to ensure that both logical segments are simultaneously verified for integrity. The first 128 bits of the integrity hash value are used as a unique anonymous identifier for the auditable key closure. Generates the internal components of the closure, containing the key ciphertext. Self-destruction proof contract on-chain address Upper bound of attribute validity period Anonymous identifiers Integrity hash value and trusted execution environment enclave metric The upper bound of the attribute's validity period Data is categorized and tiered with labels. A non-exportable signing private key is used within the trusted execution environment enclave. Digitally sign all components within the closure to generate an auditable key closure object.

[0095] Then, encrypt the data. With auditable key closure object They are uploaded to the file system network respectively. The file system uses content hashing for addressing. After a successful upload, they return encrypted Uniform Resource Identifiers. Uniform Resource Identifier with Closures . Computational data ciphertext SHA-256 hash value The data registration contract is invoked to submit an index record, which contains a data identifier. Data classification and grading labels The hash value of the encrypted data Data Encryption Uniform Resource Identifier Closure Uniform Resource Identifier Anonymous identifiers And the encryption algorithm identifier. After verifying the validity of the data owner's signature, the data registration contract writes the index record to the on-chain state database, generates a registration record, and returns a registration confirmation credential. The data requester can retrieve the data identifier of the target data by querying the on-chain index table of the data registration contract, according to the data type encoding or the data owner. Retrieve the corresponding encrypted data from the file system. With closure objects The data requester invokes the authorization contract to submit an authorization request transaction, which includes the target data identifier. Requester's public key address The request timestamp is also included. The data owner verifies the requester's identity and data access permissions off-chain. Upon successful verification, the authorization contract confirmation interface is invoked, writing the authorization mapping record between the data identifier and the requester's public key address into the on-chain state database. Simultaneously, the authorization effective time and expiration time are recorded. After receiving the authorization confirmation notification, the data requester loads the closure object within its local trusted execution environment. First, verify the validity of the digital signature of the closure object to confirm that it has not been tampered with; then use the already held attribute private key. Invoke an attribute-based encryption / decryption algorithm based on ciphertext policy to cipher the key ciphertext within a trusted execution environment. Decrypt the data to recover the symmetric key. Use the recovered symmetric key to call the AES-256-GCM decryption algorithm, inputting the ciphertext data. Random initialization vector Certification Label and additional certification data After verifying the integrity of the authentication label, the original plaintext is decrypted. A controlled output strategy is implemented based on the data classification and grading labels: for Level 1 data, the complete plaintext is returned directly; for Level 2 data, field-level anonymization is performed, removing sensitive information and trade secret fields before returning the data; for Level 3 data, processing is only permitted within a trusted execution environment, returning only the calculation result without exposing the original plaintext, ultimately yielding controlled plaintext. .

[0096] Finally, after the auditable key closure is successfully decrypted and controlled plaintext is generated for the first time within the requester's Trusted Execution Environment (TEE), the TEE enclave takes a snapshot of the closure's current internal state and generates a hardware-signed remote proof report containing the integrity hash value, enclave metric, and decryption success status code. The hardware-signed remote proof report is signed with the hardware root key to ensure its unforgeability. The trusted execution environment sandbox uses a built-in temporary anonymous account, unrelated to the requester's on-chain identity, to call the registration interface of the self-destruct proof contract, submitting the remote proof report and the closure anonymous identifier. The self-destruct proof contract verifies the signature validity of the remote proof report and the consistency between the enclave metric and the initial registration value. Upon successful verification, the following records are written to the on-chain valid witness mapping table: ;in Remote proof report for hardware signature SHA-256 hash digest, This is the upper bound of the validity period of the closure's properties. The block height at which the registered transaction is packaged into the block completes the generation of the closure activation registration record. In this embodiment, parameters such as the number of data files, the upper bound of attribute validity period, and the length of the authentication tag are merely examples; those skilled in the art can set them according to actual circumstances, and this embodiment does not impose any limitations on them.

[0097] This embodiment achieves fine-grained access control based on data sensitivity by classifying and grading raw supply chain data and constructing a differentiated access policy tree, ensuring that data of different security levels receive corresponding strengths of data security protection. By employing a two-layer encryption mechanism combining symmetric and attribute encryption, it balances the efficiency of large-scale data encryption with the flexibility of fine-grained access control, thus balancing data sharing efficiency and data security requirements. By encapsulating the key ciphertext into an auditable key closure with integrity hash binding and hardware signature, and performing decryption within a trusted execution environment, the key material is completely invisible and unextractable to users, preventing data security risks caused by key leakage. By using temporary anonymous accounts to submit closures to activate registration transactions, the verifiability of the closure activation status is achieved without revealing the true identity of the data requester, effectively protecting visitor privacy and business data security. By implementing a controlled output policy based on data classification and grading, the possibility of sensitive data leakage after decryption is further reduced, improving data security, access controllability, and privacy protection levels during supply chain data sharing.

[0098] Furthermore, this embodiment provides a step-by-step approach to obtain a proof set based on controlled plaintext and closure activation registration records, through transaction revocation, overwrite erasure, and non-interactive zero-knowledge proofs, including:

[0099] Based on controlled plaintext and closure activation registration records, affected closures are marked by self-destruction proof contracts and revocation transactions are broadcast in a manner mixed with noise events to obtain a set of revoked anonymous identifiers and effective timestamps.

[0100] Based on the set of revoked anonymous identifiers, self-destruction operation logs are obtained through polling detection and overwriting erasure.

[0101] Based on the self-destruction operation log, a zero-knowledge self-destruction proof of the closure object is obtained through non-interactive zero-knowledge proof; specifically including:

[0102] The private input for the zero-knowledge proof is obtained based on the erase success status code and completion timestamp in the self-destruction operation log; based on the private input for the zero-knowledge proof, an instance of the zero-knowledge circuit is obtained by constructing an arithmetic constraint circuit; based on the instance of the zero-knowledge circuit, a proof generation algorithm is executed to obtain the zero-knowledge self-destruction proof.

[0103] Construct a set of proofs based on zero-knowledge self-destruction proofs of closure objects.

[0104] The affected closures are auditable key closure instances whose attribute validity period has expired or been actively revoked in the valid witness mapping table of the self-destruct proof contract. This is determined by polling the valid witness mapping table through the self-destruct proof contract. Noise events are random-interval events automatically generated by the noise event pool contract when there are no actual business events within a fixed time slot. These events are used to maintain a uniform event output rate from the perspective of external observers; the fixed time slot length is typically 10 seconds. A broadcast revocation transaction is an on-chain transaction where the self-destruct proof contract changes the anonymous identifier status of the affected closure to "revoked" and carries an effective timestamp. This is used to notify all clients holding the corresponding closure instance to execute the self-destruct process. The set of revoked anonymous identifiers is the set of anonymous identifiers of all auditable key closures marked as revoked in this revocation event. The effective timestamp is the block timestamp when the revocation transaction is packaged into a block, used to identify the official effective time of the revocation operation.

[0105] Polling detection involves the client sending query requests to the self-destruct proof contract at a preset polling period to compare the local activated closure state with the on-chain valid witness mapping table state. This is used to promptly detect revoked closure instances. The polling period is typically 60 seconds. Overwrite erasure involves performing multiple secure erasure operations with different byte patterns on the key ciphertext cache and symmetric key plaintext cache within the secure zone of the trusted execution environment. This ensures the irreversible destruction of key materials. The number of overwrites is typically 3. The self-destruct operation log is an immutable log generated in the trusted execution environment enclave, recording the execution status and completion time of the key erasure operations. It is stored in a hardware-protected internal operation log buffer.

[0106] Non-interactive zero-knowledge proofs are cryptographic proofs that can prove the truth of a proposition without real-time interaction between the prover and verifier, and without revealing any secret information. They are used to prove that a closure instance has completed its self-destruction operation without disclosing any execution details. The erase success status code is a fixed identifier value generated by the trusted execution environment enclave after the entire self-destruction process is completed, indicating that the key erasure operation has been successfully completed. The completion timestamp is the system timestamp of the entire self-destruction process, generated by the built-in hardware clock of the trusted execution environment, with millisecond precision. The private input of the zero-knowledge proof is secret information known only to the prover, including the erase success status code and the completion timestamp. The arithmetic constraint circuit is a circuit representation that transforms the logical proposition to be proved into a set of arithmetic constraint equations, used for proof generation and verification in the zero-knowledge proof system. The zero-knowledge circuit instance is an arithmetic constraint circuit instantiated for a specific closure self-destruction proposition. The proof generation algorithm is a concise non-interactive zero-knowledge proof generation algorithm based on the Groth16 protocol, used to generate zero-knowledge self-destruction proofs. Zero-knowledge self-destruction proofs are cryptographic proofs that a specific auditable key closure instance has completed an irreversible self-destruction operation. The proof set consists of a collection of zero-knowledge self-destruction proofs independently generated by all affected clients.

[0107] Specifically, such as Figure 4 As shown, firstly, the self-destruct proof contract continuously monitors the record status in the valid witness mapping table. Attribute revocation is triggered by any of the following conditions: the upper bound of the validity period of an attribute of a closure record in the valid witness mapping table. The validity period expires naturally if it occurs before the current block generation time; a revocation request is initiated by an attribute authority, such as when a distributor's qualification expires; or an administrative order from a regulatory agency requires immediate revocation. For revocations initiated by attribute authorities or triggered by regulatory agencies, the revocation request must be submitted to the consortium governance contract for multi-signature approval. The approval threshold is 2 / 3 or more of the participating voting nodes. After approval, the self-destruct proof contract changes the status of the anonymous identifier in the affected closure from "valid" to "revoked," generating a timestamp carrying the revocation effective date. The reversal of the transaction is recorded in the on-chain state database, and a set of reversible anonymous identifiers is generated. ,in This represents the number of closure instances affected by this reversal event. The event pool contract mixes and publishes reversal transactions with noise events in the current time slot according to a preset mixing ratio. The mixing ratio is the ratio of the number of reversal transactions to the number of noise events, typically set to 1:3, making it impossible for external observers to distinguish reversal operations from regular business operations based on transaction frequency or timing characteristics.

[0108] Then, each data requester client holding an activated auditable key closure instance polls according to a preset cycle. A query request is sent to the valid witness mapping table of the self-destruct proof contract to obtain the latest state of the locally activated closures. The on-chain state returned by the contract is compared item by item with the locally maintained list of anonymous identifiers for activated closures. When an anonymous identifier is detected as "revoked" in the valid witness mapping table, or when the current system time exceeds the upper bound of the validity period of the attribute corresponding to the closure, the self-destruct process of the closure is immediately triggered. The closure sandbox has a pre-set non-maskable interruption mechanism. Once a revocation signal is received, this mechanism immediately seizes CPU control, preventing any application-layer code from continuing execution. After the self-destruct process gains enforcement power, the key ciphertext is encrypted within the secure zone of the trusted execution environment. Cache copies and data symmetric keys The plaintext cache undergoes multiple overwrite secure erase operations, using the DOD5220.22-M standard. The overwrite process sequentially writes one all-zero byte (0x00), one all-one byte (0xFF), and a random byte sequence. After erasure, the entire memory space of the trusted execution environment's secure zone is traversed and checked to confirm that there are no readable residual references to the aforementioned key material. The execution status code and completion timestamp of the erasure operation are recorded. Write to the hardware-protected internal operation log buffer to form a local self-destruct operation log. .

[0109] Finally, from the local self-destruct operation log Extract the erase success status code and completion timestamp As the private input of a zero-knowledge proof system Determine the public input set for zero-knowledge proofs. ,in For the anonymous identifier of the closure to be proven, To revoke the effective timestamp, The verification key identifier generated during the system initialization phase. Construct an arithmetic constraint circuit that expresses the following proposition: "There exists a valid auditable key closure instance whose anonymous identifier..." It has been marked as revoked in the on-chain self-destruct proof contract, and the instance has been in revocation status since the revocation took effect. "A complete irreversible key erasure operation was previously performed." This arithmetic constraint circuit is expressed using a first-order constraint system R1CS, encoding the hash value of the secret witness and the conditions for the completion of the self-destruction operation into a set of constraint equations. The public reference string generated and published by the secure multi-party computation protocol during the system initialization phase is loaded. The algorithm for generating non-interactive zero-knowledge proofs based on the Groth16 protocol is executed, and the calculation formula is as follows: ;in This is a system-wide public reference string, containing the common portion of the proof key and the verification key; For public input set; For private input; For the generated zero-knowledge self-destruct proof, This is a concise, non-interactive zero-knowledge proof generation algorithm based on the Groth16 protocol. It features small proof size and low verification computational cost, and is used to generate publicly verifiable zero-knowledge proofs. This section represents the algorithm's operations and result assignments. The left side shows the output of the proof generation algorithm, and the right side shows the proof generation algorithm and its input parameters. After each affected client independently completes the above proof generation, it will generate a zero-knowledge self-destruct proof. The zero-knowledge self-destruct proofs generated by all clients are temporarily stored locally, together forming a proof set. In this embodiment, the parameters such as fixed time slot length, polling period, number of overwrites, number of circuit constraints, and mixing ratio are merely examples. Those skilled in the art can set them according to actual conditions, and this embodiment does not impose any restrictions on them.

[0110] This embodiment achieves flexible and secure attribute revocation management by constructing a multi-dimensional revocation trigger mechanism that combines automatic expiration, authoritative attribute revocation, and mandatory instructions from regulatory agencies. It also introduces a multi-signature approval process for alliance governance, ensuring dynamic control over data security permissions. By setting up unblockable interruptible forced execution of multiple overwrite security erasures within a trusted execution environment, it ensures the irreversible destruction of key materials, preventing the risk of unauthorized decryption of revoked data. Employing the Groth16 non-interactive zero-knowledge proof protocol, it generates self-destruction proofs using local self-destruct logs as secret witnesses, achieving verifiability of self-destruction without revealing any execution details, thus protecting business operation privacy while ensuring data security. By mixing revocation transactions with noise events in a preset ratio, it effectively prevents attacks by external observers from inferring sensitive business information through statistical transaction timing characteristics, further enhancing the system's data security protection capabilities. This embodiment solves the problems of incomplete attribute revocation, unauditable self-destruction processes, and easily traceable revocation operations in traditional supply chain data sharing, improving the closed-loop management of data security throughout the entire lifecycle of supply chain data sharing, and enhancing the security, auditability, and privacy protection level of the data destruction process.

[0111] Furthermore, this embodiment provides a step for obtaining compliance audit conclusions based on a set of proofs through recursive knowledge argument aggregation and zero-knowledge verification, including:

[0112] Based on the proof set, aggregated proofs are obtained through recursive knowledge argument aggregation using a binary tree structure; specifically including:

[0113] Based on the proof set, a sequence of proof pairs is obtained by constructing a proof merging tree; based on the sequence of proof pairs, the intermediate aggregated proofs are obtained by verifying the validity of the keys; based on the root node of the proof merging tree and the intermediate aggregated proofs, the aggregated proof is obtained through recursive verification in the final round.

[0114] Based on aggregate proof, compliance audit conclusions are obtained through zero-knowledge verification.

[0115] The binary tree structure is a hierarchical tree data structure where each node has at most two child nodes. It is used to organize multiple discrete zero-knowledge proofs into a hierarchical structure that can be merged layer by layer. Recursive knowledge proof aggregation is a proof compression method based on recursive zero-knowledge proof technology. It encodes the verification process of multiple independent zero-knowledge proofs into arithmetic circuits and generates new proofs, merging a large number of scattered zero-knowledge self-destructing proofs into a single aggregated proof to reduce the computational overhead of audit verification. The aggregated proof is a single cryptographic proof generated after recursive knowledge proof aggregation, capable of simultaneously proving that all original zero-knowledge self-destructing proofs it contains are valid. The proof merging tree is a complete binary tree constructed with each zero-knowledge self-destructing proof in the proof set as a leaf node, built by pairing proofs at the same level. The proof pair sequence is an ordered sequence formed by pairing all proofs at the same level in the proof merging tree in sequence. Verification key validity is an operation that uses a verification key generated and published by a secure multi-party computation protocol during the system initialization phase to verify the mathematical correctness of a single zero-knowledge proof, used to confirm that all sub-proofs to be aggregated are legal and valid. The layer-by-layer intermediate aggregation proof is generated by merging two verified sub-proofs at each level of the proof merging tree, retaining only the conclusion that the sub-proof has been verified as valid and excluding the original proof content. The root node of the proof merging tree is the top-level node, corresponding to the input of the last round of recursive aggregation. The final round of recursive verification is the process of performing final verification and merging operations on the two intermediate aggregation proofs at the root node of the proof merging tree to generate the final aggregation proof. Zero-knowledge verification is the process of performing a single verification calculation on the aggregation proof using the system's publicly available verification key, used to confirm that all self-destruction operations covered by the aggregation proof have been completed in compliance with regulations. The compliance audit conclusion is a structured record generated based on the zero-knowledge verification results, including the audit timestamp, revocation batch number, number of affected closure instances, and verification pass status, for alliance members to review without disclosing any sensitive business information.

[0116] Specifically, such as Figure 5 As shown, firstly, the off-chain aggregation module of the self-destruct proof contract aggregates according to the preset aggregation period. Collect all zero-knowledge self-destruct proofs generated during this aggregation cycle to form a set of proofs to be aggregated. ,in The total number of zero-knowledge self-destruct proofs within this aggregation period, and the aggregation period. The unit is the number of blocks in the consortium blockchain, typically taken as 10 blocks. This is based on the number of proofs to be aggregated. If the value is not a power of 2, then copy the last zero-knowledge self-destruct proof in the set. Pad to the nearest power of 2 This ensures that a complete binary tree can be constructed. (The result is after the tree is completed.) Each zero-knowledge self-destruct proof is used as a leaf node, constructing a system with a depth of... The proof merging tree pairs proofs at the same level in sequence to form a sequence of proof pairs. For each pair of sub-proofs in the sequence. The recursive validator invokes a recursive verification circuit based on the Groth16 protocol, using the verification key generated during the system initialization phase and written into the self-destruct proof contract. The validity of the two sub-proofs is verified separately. The calculation formula is constructed based on the Groth16 recursive verification criterion, specifically as follows: ;in This is the system's global verification key; , These are the public input sets corresponding to the two sub-proofs; , These are two sub-proofs to be verified; To verify the Boolean value of the result, a value of true indicates that both sub-proofs are valid. This is a concise, non-interactive zero-knowledge proof verification algorithm based on the Groth16 protocol, used to verify the mathematical correctness and legality of zero-knowledge proofs, with verification computation having constant time complexity. This is a logical AND operation, indicating that the final verification result is true only if both sub-proofs pass verification simultaneously. This ensures that all sub-proofs participating in the aggregation are valid. If the verification result is true, the valid statements of the two sub-proofs are compressed into a single intermediate aggregated proof. The intermediate aggregate proof only contains the conclusion that "both sub-proofs have been verified as valid" and does not contain any details of the original proof. This merging operation is performed layer by layer upwards in the proof merging tree, with the intermediate aggregate proof generated at each layer serving as the input sub-proof for the layer above, thus obtaining proofs from layer 1 to layer 2. The layer-by-layer set of intermediate aggregated proofs. Upon reaching the root node of the proof merging tree, the final round of recursive verification and merging operations are performed on the last two intermediate aggregated proofs, generating a single aggregated proof representing that all zero-knowledge self-destruct proofs within this aggregation cycle are valid. Aggregate proof Associated cancellation batch number Number of affected closures The public statement declares that the destruction witness of the self-destruction proof contract is written into the transaction and recorded in the on-chain destruction witness mapping table for subsequent audit and query.

[0117] Then, when the regulatory agency initiates a compliance audit, the regulatory audit node submits an audit query request to the self-destruct proof contract, with the request input being the revocation batch number to be reviewed. The self-destruct proof contract quickly retrieves the aggregate proof storage identifier bound to that batch based on the revocation batch number index. Number of affected closures and the revocation effective timestamp Store identifiers based on aggregate proofs. Retrieve the complete aggregated proof data object from the on-chain state database or the off-chain distributed file system. Use the global authentication key disclosed during the system initialization phase. A single zero-knowledge verification calculation is performed, and the calculation formula is based on the Groth16 verification standard, specifically as follows: ;in This is the system's global verification key; A public statement for this batch cancellation, including the batch cancellation number. Number of affected closures and the revocation effective timestamp ; For the aggregate proof to be verified; This is a Boolean value representing the audit verification result. The verification calculation has constant time complexity, and its computational cost is independent of the number of original zero-knowledge self-destruct proofs before aggregation. If the verification result... If true, a compliance audit conclusion is generated: "Verified by zero-knowledge proof, consistent with the revoked batch..." All related All auditable key closure instances have been revoked within the effective timeframe. "Having previously completed irreversible key erasure and self-destruction operations, all affected data requesters have lost the ability to decrypt the relevant encrypted data." If the verification result is false, an audit anomaly conclusion is generated, indicating the existence of a closure instance that has not completed self-destruction. The SHA-256 hash value of the audit conclusion and the audit timestamp are written into the consortium blockchain for evidence storage, generating an immutable audit record. In this embodiment, parameters such as aggregation period and proof merging tree depth are merely examples; those skilled in the art can set them according to actual conditions, and this embodiment does not impose any limitations on them.

[0118] This embodiment employs a recursive knowledge proof aggregation technique based on a binary tree structure to compress a large number of scattered zero-knowledge self-destruction proofs into a single aggregated proof. This makes the audit verification overhead independent of the number of original proofs, achieving lightweight large-scale compliance auditing and reducing the cost of data security compliance auditing. By using a zero-knowledge verification algorithm based on the Groth16 protocol, it ensures that the audit process only verifies the authenticity of the self-destruction fact without disclosing any data content, visitor identity, or business operation details, thus comprehensively protecting the privacy of supply chain businesses. By storing the aggregated proof and the hash value of the audit conclusion on the blockchain, it achieves the immutability and traceability of audit results. Through an architecture combining off-chain aggregation and on-chain verification, it balances the efficiency of aggregation computation with the credibility of verification results, solving the problems of low audit efficiency, high risk of privacy leakage, and unreliable audit results in traditional supply chain data sharing. It improves the efficiency, security, and credibility of supply chain data sharing compliance auditing while ensuring data security and business privacy.

[0119] Example 2:

[0120] like Figure 6 As shown, this embodiment provides a blockchain-based supply chain data sharing system, including:

[0121] Environment initialization module: Used to generate attribute encryption parameters and master private key fragments based on the consortium blockchain network through distributed attribute authority, and initialize the runtime environment in the trusted execution environment;

[0122] Encrypted sharing module: Based on the runtime environment, it uses access policy to encapsulate the data in a double-layer encryption and register it on the chain. Then, it decrypts the data in a trusted execution environment to obtain controlled plaintext and closure activation registration records.

[0123] Self-destruction proof module: Used to obtain a set of proofs based on controlled plaintext and closure activation registration records, through transaction reversal, overwriting and erasure, and non-interactive zero-knowledge proofs;

[0124] Aggregated Audit Module: Used to obtain compliance audit conclusions based on a set of proofs through recursive knowledge argument aggregation and zero-knowledge verification.

[0125] The environment initialization module, encryption sharing module, self-destruct proof module, and aggregation audit module are all located on the server. The server receives data transmitted from the acquisition device and performs further analysis. The environment initialization module first builds a consortium blockchain network based on a practical Byzantine fault-tolerant consensus protocol and divides it into isolated channels according to business domains. It deploys distributed attribute authorities and generates attribute encryption parameters and master private key threshold shards through secure multi-party computation. It then deploys an on-chain business function contract set consisting of a data registration contract, authorization management contract, self-destruct proof contract, and noise event pool contract. Finally, it generates blockchain identities and data symmetric keys for each participant and completes remote proof binding in a trusted execution environment, constructing a hardware-level secure operating environment. The encryption sharing module classifies and grades the raw supply chain data and constructs a differentiated access policy tree. It adopts a two-layer encryption mechanism combining symmetric encryption and attribute encryption based on ciphertext policies. It encapsulates the key ciphertext into an auditable key closure and completes on-chain registration. Within the trusted execution environment, it performs attribute decryption and controlled output, while simultaneously activating the closure registration through anonymous transactions. The self-destruct proof module generates reversal transactions through a multi-dimensional triggering mechanism combining automatic expiration, attribute authority-driven revocation, and mandatory instructions from regulatory agencies. Within a trusted execution environment, it enforces key overwriting and erasure using an unblockable interruptible execution method. Based on local self-destruction operation logs, it generates non-interactive zero-knowledge self-destruct proofs and assembles them into a proof set. The aggregation audit module uses a binary tree structure to recursively aggregate the proof set through knowledge verification, compressing numerous scattered zero-knowledge proofs into a single aggregated proof. Regulatory agencies can confirm the compliance of all self-destruction operations through a single zero-knowledge verification, generating a structured audit conclusion that does not disclose any sensitive information and storing it on the blockchain.

[0126] In summary, this invention achieves trusted sharing of supply chain data within secure isolation boundaries by constructing a consortium blockchain network based on practical Byzantine fault-tolerant consensus and dividing it into isolated channels according to business domains; it eliminates single-point key escrow risks and achieves decentralized attribute key management by deploying distributed attribute authorities and generating attribute encryption parameters and master private key threshold sharding through secure multi-party computation; it achieves fine-grained access control of key materials that are invisible and unextractable to users through a two-layer encryption mechanism combining symmetric encryption and attribute encryption based on ciphertext policies, as well as auditable key closure technology; it achieves verifiability of closure activation state without revealing the visitor's identity through a trusted execution environment hardware signature remote proof and anonymous transaction registration mechanism; it achieves verifiability of self-destruction facts without exposing execution details through non-maskable interruptible forced key overwriting and erasure and non-interactive zero-knowledge self-destruction proof technology; and it achieves lightweight large-scale compliance auditing without revealing any sensitive business information through recursive knowledge argument aggregation and zero-knowledge verification technology. This embodiment addresses the problems existing in traditional supply chain data sharing, such as coarse access control granularity, high key management risks, incomplete attribute revocation, unauditable self-destruction process, low audit efficiency, and serious privacy leaks. It improves the security, auditability, and privacy protection level of supply chain data sharing throughout its entire lifecycle, and provides a complete technical solution for trusted data sharing and compliant supervision across the entire supply chain.

[0127] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0128] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0129] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0130] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A blockchain-based supply chain data sharing method, characterized in that, include: Based on the consortium blockchain network, attribute encryption parameters and master private key fragments are generated through distributed attribute authority, and the runtime environment is obtained by initialization in a trusted execution environment. Based on the aforementioned operating environment, after double-layer encryption and on-chain registration of the access policy, the controlled plaintext and closure activation registration record are obtained by decryption in the trusted execution environment. Based on the controlled plaintext and closure activation registration record, a set of proofs is obtained through transaction revocation, overwrite erasure, and non-interactive zero-knowledge proof. Based on the aforementioned set of proofs, compliance audit conclusions are obtained through recursive knowledge argument aggregation and zero-knowledge verification.

2. The blockchain-based supply chain data sharing method according to claim 1, characterized in that, The process, based on a consortium blockchain network, generates attribute encryption parameters and master private key shards through a distributed attribute authority, and initializes them in a trusted execution environment to obtain the runtime environment, including: Based on supply chain needs, a consortium blockchain network is obtained by deploying a practical Byzantine fault-tolerant consensus protocol and dividing business isolation channels. Based on the aforementioned consortium blockchain network, the attribute encryption parameters and master private key fragments are obtained by deploying independent attribute authorities by supply chain participants and using secure multi-party computation and collaborative operation. Based on the aforementioned consortium blockchain network and attribute encryption parameters, an on-chain business function contract set is obtained by deploying smart contracts. Based on the aforementioned on-chain business function contract set, the operating environment is obtained by generating blockchain identity, data symmetric key, and performing remote proof binding.

3. The blockchain-based supply chain data sharing method according to claim 2, characterized in that, The process, based on the consortium blockchain network, involves supply chain participants deploying independent attribute authorities and using secure multi-party computation to collaboratively obtain attribute encryption parameters and master private key shards, including: Based on the aforementioned consortium blockchain network, a distributed set of attribute authorities is obtained by deploying independent attribute authorities by supply chain participants and defining attribute namespaces and review processes. Based on the distributed attribute authority set, attribute encryption parameters and master private key fragments are obtained by selecting random shares and inputting them into a secure multi-party computation protocol for joint operation.

4. The blockchain-based supply chain data sharing method according to claim 3, characterized in that, Based on the aforementioned operating environment, the controlled plaintext and closure activation registration record are obtained by double-layer encryption encapsulation of the access policy, on-chain registration, and decryption in the trusted execution environment, including: Based on the operating environment and raw supply chain data, data classification and grading labels are obtained through sensitivity assessment and business domain classification. Based on the data classification and grading labels, an access policy tree is constructed, attribute encryption based on the ciphertext policy is performed, and then the data is encapsulated to obtain the ciphertext and closure object. Based on the encrypted data and the closure object, the registration record and controlled plaintext are obtained through on-chain registration index, attribute decryption and controlled output; Based on the controlled plaintext, a closure activation registration record is obtained by generating a hardware-signed remote proof report and submitting it to the self-destruct proof contract via an anonymous transaction.

5. The blockchain-based supply chain data sharing method according to claim 4, characterized in that, The process, based on the data classification and grading labels, involves constructing an access policy tree, performing attribute encryption based on a ciphertext policy, and then encapsulating the data to obtain ciphertext and a closure object, including: Based on the data classification and hierarchical labels, an access strategy tree is constructed according to the attribute namespace; Based on the aforementioned symmetric key, the plaintext is encrypted using the AES-256-GCM algorithm, and an authentication tag is generated to obtain the ciphertext. Based on the access policy tree and the data symmetric key, the data symmetric key is encrypted by calling the attribute encryption algorithm based on the ciphertext policy to obtain the key ciphertext; Based on the key ciphertext, the internal components of the closure are obtained by calculating the integrity hash of the decryption logic and the self-destruction logic and generating an anonymous identifier, and then packaged with a digital signature to obtain the closure object.

6. The blockchain-based supply chain data sharing method according to claim 1, characterized in that, The set of proofs obtained based on the controlled plaintext and closure activation registration record, through transaction revocation, overwrite erasure, and non-interactive zero-knowledge proofs, includes: Based on the controlled plaintext and closure activation registration record, the affected closure is marked by the self-destruct proof contract and the revocation transaction is broadcast in a manner mixed with noise events to obtain the set of revoked anonymous identifiers and the effective timestamp; Based on the set of revoked anonymous identifiers, self-destruction operation logs are obtained through polling detection and overwriting erasure. Based on the self-destruction operation log, a zero-knowledge self-destruction proof of the closure object is obtained through non-interactive zero-knowledge proof, and a proof set is constructed based on the zero-knowledge self-destruction proof of the closure object.

7. The blockchain-based supply chain data sharing method according to claim 6, characterized in that, The process of obtaining a zero-knowledge self-destruction proof of the closure object through non-interactive zero-knowledge proof based on the self-destruction operation log, and constructing a proof set based on the zero-knowledge self-destruction proof of the closure object, includes: The zero-knowledge proof private input is obtained based on the erase success status code and completion timestamp in the self-destruct operation log. Based on the private input of the zero-knowledge proof, an instance of a zero-knowledge circuit is obtained by constructing an arithmetic constraint circuit. Based on the zero-knowledge circuit instance, a zero-knowledge self-destruct proof is obtained by executing a proof generation algorithm.

8. The blockchain-based supply chain data sharing method according to claim 1, characterized in that, The compliance audit conclusion obtained based on the aforementioned set of proofs through recursive knowledge argument aggregation and zero-knowledge verification includes: Based on the aforementioned set of proofs, an aggregated proof is obtained by recursively aggregating knowledge arguments using a binary tree structure. Based on the aggregated proof, a compliance audit conclusion is obtained through zero-knowledge verification.

9. The blockchain-based supply chain data sharing method according to claim 8, characterized in that, The process of obtaining aggregated proofs based on the aforementioned set of proofs through recursive knowledge argumentation using a binary tree structure includes: Based on the set of proofs, a sequence of proof pairs is obtained by constructing a proof merging tree; Based on the aforementioned proof pair sequence, the layer-by-layer intermediate aggregation proof is obtained by verifying the validity of the key; Based on the root node of the proof merging tree and the intermediate aggregation proofs layer by layer, the aggregate proof is obtained through recursive verification in the final round.

10. A blockchain-based supply chain data sharing system, used to implement the blockchain-based supply chain data sharing method according to any one of claims 1-9, characterized in that, The system includes: The environment initialization module is used to generate attribute encryption parameters and master private key fragments based on the consortium blockchain network through distributed attribute authority, and to initialize the runtime environment in the trusted execution environment. The encrypted sharing module is used to obtain controlled plaintext and closure activation registration record by double-encapsulating access policies and registering them on the chain based on the operating environment and then decrypting them in the trusted execution environment. The self-destruction proof module is used to obtain a set of proofs based on the controlled plaintext and the closure activation registration record by revoking transactions, overwriting and erasing, and non-interactive zero-knowledge proofs. The aggregate audit module is used to obtain compliance audit conclusions based on the set of proofs through recursive knowledge argument aggregation and zero-knowledge verification.

Images