A Blockchain-Based Trusted Traceability Method and System for the Entire Lifecycle of Pharmaceutical Data

Abstract

This invention discloses a blockchain-based method and system for trusted traceability of pharmaceutical lifecycle data, relating to the field of pharmaceutical supply chain management. The method includes: adding multiple circulation nodes to a consortium blockchain network and configuring data permissions for each node; extracting multiple sets of associated circulation nodes linked to multiple data uploading stages from each node, and performing encrypted joint verification using an asynchronous key splitting mechanism; upon successful verification, the sets of associated circulation nodes upload data to the blockchain according to their respective data permissions; and having the target user scan the drug identifier using a terminal device to trace the data on the consortium blockchain network, and then uploading the drug usage data to the blockchain via off-chain storage and on-chain indexing after feedback and review, thus completing closed-loop traceability. This method solves the technical problem of incompatibility between privacy protection and cross-stage trusted collaboration in existing trusted traceability systems, achieving the technical effect of both privacy protection and trusted cross-stage sharing.

Description

Technical Field

[0001] This application relates to the field of pharmaceutical supply chain management, and in particular to a blockchain-based method and system for trusted traceability of drug lifecycle data. Background Technology

[0002] Trustworthy traceability of pharmaceutical data throughout its entire lifecycle is a core element in ensuring drug safety, preventing the circulation of counterfeit drugs, and achieving quality supervision. The authenticity, completeness, and cross-stage collaboration of this data directly impact public health security and the trust system of the pharmaceutical industry. Current technologies primarily rely on a single blockchain architecture for drug traceability, storing the entire process data on-chain and relying on digital signatures to verify node legitimacy. However, the homogeneous node design of this single blockchain architecture results in all nodes having equal access to all data, making sensitive information easily accessible to unauthorized nodes. Furthermore, a single consensus mechanism cannot adapt to the varying levels of trust at different stages of drug distribution, leading to risks of data privacy breaches and low efficiency in cross-stage collaboration.

[0003] Currently, in related technologies, there are technical issues with the reliable traceability of drug lifecycle data, namely the incompatibility between privacy protection and reliable cross-stage collaboration. Summary of the Invention

[0004] This application provides a blockchain-based method and system for trusted traceability of pharmaceutical lifecycle data. It employs a blockchain network to construct a pharmaceutical lifecycle consortium blockchain and allocate differentiated data permissions. An asynchronous key splitting mechanism is used to perform encrypted joint verification of the associated node sets at each stage of the process. After verification, data is uploaded to the blockchain in stages according to permissions. Users scan codes for traceability and receive feedback on the data used. After review, the data is uploaded to the blockchain in a closed-loop manner using "off-chain storage + on-chain indexing." These technical means solve the existing technical problem of incompatibility between privacy protection and trusted cross-stage collaboration in trusted traceability of pharmaceutical lifecycle data, achieving the technical effect of both privacy protection and trusted cross-stage sharing.

[0005] This application provides a blockchain-based method for trusted traceability of pharmaceutical lifecycle data, comprising: constructing a consortium blockchain network, adding multiple circulation nodes throughout the pharmaceutical lifecycle to the consortium blockchain network, and configuring multiple data permissions for each circulation node; extracting multiple sets of associated circulation nodes from the multiple circulation nodes, each set of associated circulation nodes being linked to multiple data on-chain stages, and performing encrypted joint verification on the multiple sets of associated circulation nodes through an asynchronous key splitting mechanism; when the encrypted joint verification passes, the multiple sets of associated circulation nodes upload data to the blockchain for multiple data on-chain stages according to the multiple data permissions; when a target user scans the pharmaceutical label through a terminal device, the consortium blockchain network is used for pharmaceutical lifecycle data traceability, and the pharmaceutical usage data is uploaded to the blockchain through off-chain storage and on-chain indexing after feedback review, thus completing closed-loop traceability.

[0006] In a possible implementation, the following processing is performed: the multiple circulation nodes include raw material supply nodes, drug production nodes, warehousing and transportation nodes, wholesale and retail nodes, medical institution nodes, and patient nodes.

[0007] In a possible implementation, multiple sets of associated circulation nodes, each associated with a different data on-chain stage, are extracted from the multiple circulation nodes. An asynchronous key splitting mechanism is used to perform encrypted joint verification on each of these sets. When the encrypted joint verification passes, the multiple sets of associated circulation nodes upload data to the blockchain for each of the multiple data on-chain stages according to the multiple data permissions, performing the following processing: extracting a first data on-chain stage from the multiple data on-chain stages, and extracting a first set of associated circulation nodes from the multiple sets of associated circulation nodes; randomly generating a first master key based on the trusted hardware module of the consortium blockchain network; obtaining the number of nodes in the first set of associated circulation nodes, and combining this with a dynamic blank node generator to obtain the dynamic splitting quantity; and then, based on the dynamic splitting quantity... The first master key is asynchronously split based on an asynchronous key splitting mechanism to obtain a set of split sub-keys. The set of split sub-keys is randomly distributed to the first set of associated circulation nodes through different channels for identity binding to obtain a set of first associated circulation node-bound split sub-keys. When the first data on-chain stage is triggered, the first set of associated circulation nodes can sign the data hash through the IoT chip and perform encrypted joint verification in combination with the set of first associated circulation node-bound split sub-keys. If the number of valid first associated circulation node-bound split sub-keys in the set of first associated circulation node-bound split sub-keys is greater than or equal to a preset threshold, the consortium blockchain network recovers the first master key through a threshold reconstruction algorithm to complete the encrypted joint verification.

[0008] In a possible implementation, based on the dynamic segmentation quantity, the first master key is asynchronously segmented using an asynchronous key segmentation mechanism to obtain a set of segmented sub-keys. The following processes are then performed: obtaining a historical set of segmented sub-keys; retrieving the initial key segmentation bandwidth in the asynchronous key segmentation mechanism, performing a first segmentation on the first master key, and verifying key reliability using the historical set of segmented sub-keys; if the verification passes, obtaining a first sub-key and a first segmented master key; if the verification fails, adjusting the initial key segmentation bandwidth multiple times using a random adjustment method to obtain multiple adjusted key segmentation bandwidths, and using the multiple adjusted key segmentation bandwidths to perform a first segmentation on the first master key to obtain multiple adjusted sub-keys, verifying key reliability for each of the multiple adjusted sub-keys to obtain a first sub-key and a first segmented master key; performing a second segmentation on the first segmented master key again using the initial key segmentation bandwidth, and verifying key reliability using the historical set of segmented sub-keys, until the number of segmentations satisfies the dynamic segmentation quantity minus 1, thus obtaining the set of segmented sub-keys.

[0009] In a possible implementation, the initial key splitting bandwidth of the asynchronous key splitting mechanism is retrieved, the first master key is split for the first time, and key reliability verification is performed in conjunction with the historical split sub-key set. If the verification passes, the first split sub-key and the first split master key are obtained, and the following processing is performed: the initial key splitting bandwidth of the asynchronous key splitting mechanism is retrieved, the first master key is split for the first time, and the first initial split sub-key is obtained; the matching similarity between the first initial split sub-key and the historical split sub-keys in the historical split sub-key set is calculated, and the matching similarity set is obtained; the mean of the matching similarity set is calculated, and the reciprocal of the calculation result is used as the key reliability coefficient; it is determined whether the key reliability coefficient is greater than or equal to a preset key reliability coefficient threshold. If so, the verification passes, the first initial split sub-key is used as the first split sub-key, and the remaining part after splitting the first master key is used as the first split master key.

[0010] In a possible implementation, the number of nodes in the first associated flow node set is obtained, and the number of dynamic splits is obtained by combining the dynamic blank node generator. The following processing is performed: the preset maximum number of blank nodes is obtained; a first random number is randomly generated based on the dynamic blank node generator, and the first random number is multiplied by the preset maximum number of blank nodes to obtain the number of dynamic blank nodes; the number of dynamic blank nodes is added to the number of nodes in the first associated flow node set to obtain the number of dynamic splits.

[0011] In a possible implementation, when the cryptographic joint verification passes, multiple sets of associated circulation nodes perform multiple data uploading stages on the blockchain according to the multiple data permissions. Then, the following processes are executed: triggering a real-time verification instruction for the smart contract deployed on the consortium blockchain network; based on the real-time verification instruction, calling the IoT device signatures of multiple sets of associated circulation nodes for signature verification, and performing integrity verification on the uploaded data to obtain multiple real-time verification results, where each real-time verification result includes a signature verification result and an integrity verification result; and implementing a penalty and reward mechanism for the multiple sets of associated circulation nodes based on the multiple real-time verification results.

[0012] In a possible implementation, the following processing is performed: the penalty and reward mechanism includes deducting a preset reputation value from the associated circulation node when either the signature verification result or the integrity verification result fails, and counting the number of deductions. When the number of deductions exceeds a preset deduction threshold, a penalty measure is triggered. When both the signature verification result and the integrity verification result pass, a preset reputation value is increased for the associated circulation node, and the number of increases is counted. When the number of increases exceeds a preset increase threshold, an incentive measure is triggered.

[0013] In a possible implementation, the following processing is performed: the consortium blockchain network adopts a Byzantine fault-tolerant or proof-of-authority consensus mechanism to ensure data consistency among multiple circulation nodes.

[0014] This application also provides a blockchain-based trusted traceability system for the entire lifecycle of pharmaceutical data, comprising: a consortium blockchain network construction module, used to construct a consortium blockchain network, add multiple circulation nodes throughout the entire lifecycle of the pharmaceutical data to the consortium blockchain network, and configure multiple data permissions for each circulation node; an encrypted joint verification module, used to extract multiple sets of associated circulation nodes related to multiple data on-chain stages from the multiple circulation nodes, and perform encrypted joint verification on the multiple sets of associated circulation nodes through an asynchronous key splitting mechanism. When the encrypted joint verification passes, the multiple sets of associated circulation nodes upload data to the blockchain for multiple data on-chain stages according to the multiple data permissions; and a traceability module, used to trace the pharmaceutical data throughout its entire lifecycle through the consortium blockchain network when a target user scans the pharmaceutical label using a terminal device, and uploads the pharmaceutical usage data to the blockchain through off-chain storage and on-chain indexing after feedback review, thus completing closed-loop traceability.

[0015] The proposed blockchain-based method and system for trusted traceability of pharmaceutical lifecycle data first constructs a consortium blockchain network, adding multiple circulation nodes throughout the pharmaceutical lifecycle to the network and configuring multiple data permissions for each node. Then, it extracts multiple sets of associated circulation nodes related to various data uploading stages from these nodes. An asynchronous key splitting mechanism is used to perform encrypted joint verification on these sets of associated circulation nodes. When the encrypted joint verification passes, the sets of associated circulation nodes upload data to the blockchain according to the specified data permissions for each stage. Finally, when a target user scans the pharmaceutical label using a terminal device, the consortium blockchain network performs data traceability throughout the pharmaceutical lifecycle. The pharmaceutical usage data is then reviewed and verified before being uploaded to the blockchain via off-chain storage and on-chain indexing, completing the closed-loop traceability. This achieves the technical effects of privacy protection and trusted sharing across different stages. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings of the embodiments of the present invention will be briefly described below. Flowcharts are used in this application to illustrate the operations performed by the system according to the embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed precisely in sequence. Instead, various steps can be processed in reverse order or simultaneously as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from these processes.

[0017] Figure 1 A flowchart illustrating the blockchain-based trusted traceability method for the entire lifecycle of pharmaceutical data provided in this application embodiment.

[0018] Figure 2 A schematic diagram of the structure of a blockchain-based trusted traceability system for the entire lifecycle of pharmaceutical data provided in this application embodiment.

[0019] Figure labeling: Consortium blockchain network construction module 10, cryptographic joint verification module 20, traceability module 30. Detailed Implementation

[0020] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below.

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description of this application will be provided in conjunction with the accompanying drawings. The described embodiments should not be considered as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] In the following description, references to "some embodiments" describe a subset of all possible embodiments. However, it is understood that "some embodiments" can be the same or different subsets of all possible embodiments and can be combined with each other without conflict. The terms "first" and "second" are used merely to distinguish similar objects and do not represent a specific ordering of objects. The terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or modules not explicitly listed or inherent to these processes, methods, products, or devices. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only.

[0023] This application provides a blockchain-based method for trusted traceability of drug lifecycle data, such as... Figure 1 As shown, the method includes:

[0024] Step S100: Construct a consortium blockchain network, add multiple circulation nodes throughout the entire life cycle of the drug to the consortium blockchain network, and configure multiple data permissions for each circulation node. The multiple circulation nodes include raw material supply nodes, drug production nodes, warehousing and transportation nodes, wholesale and retail nodes, medical institution nodes, and patient nodes. The consortium blockchain network adopts Byzantine fault tolerance or proof-of-authority consensus mechanism to ensure data consistency among multiple circulation nodes.

[0025] Specifically, the consortium blockchain network is built using open-source consortium blockchain frameworks such as Hyperledger Fabric and FISCO BCOS as the underlying framework. The consortium blockchain is jointly maintained by multiple pre-authorized organizations, balancing decentralization and access control. An independent blockchain node is deployed for each circulation node, including raw material suppliers, drug manufacturers, warehousing and transportation, wholesale and retail, medical institutions, patients, and regulatory agencies. Nodes communicate with each other via a P2P network. The consortium blockchain network employs either Byzantine fault tolerance or proof-of-authority consensus mechanisms. Byzantine fault tolerance allows for the presence of some faulty or malicious nodes while still ensuring normal system operation. Proof-of-authority consensus mechanisms rely on a minority of authoritative nodes to verify transactions, suitable for high-throughput scenarios. For example, authoritative nodes such as regulatory agencies and large pharmaceutical companies act as validators, confirming transactions through pre-authorized signatures, thus improving transaction processing efficiency.

[0026] Data access permissions can be configured through permission management contracts written in Solidity or Chaincode. For example, raw material supply nodes can only upload data such as raw material batches and quality inspection reports; medical institution nodes can query the entire drug process data, but can only upload patient medication records. Simultaneously, sensitive data, such as patient privacy, is encrypted using attribute-based encryption, and only users meeting specific attribute requirements, such as doctors in top-tier hospitals, can decrypt and view it.

[0027] Step S200: Extract multiple sets of associated transfer nodes that are associated with multiple data on-chain stages from the multiple transfer nodes respectively. Perform encrypted joint verification on the multiple sets of associated transfer nodes respectively through an asynchronous key splitting mechanism. When the encrypted joint verification is successful, the multiple sets of associated transfer nodes perform data on-chain for multiple data on-chain stages according to the multiple data permissions.

[0028] Specifically, the drug lifecycle is divided into stages such as raw material procurement, production, transportation, sales, and use, with each stage associated with a specific set of nodes. For example, the production stage is associated with raw material supply nodes and production nodes; the transportation stage is associated with warehousing and transportation nodes and wholesale and retail nodes. The mapping relationship between nodes and stages is defined through smart contracts, such as "if the drug batch is X, then the production stage must include raw material supply nodes and drug production nodes."

[0029] Asynchronous key splitting refers to dividing the encryption key into multiple parts, each held by a different node, requiring collaboration for decryption or signing. For example, using the Shamir secret sharing scheme, the master key is split into n parts and distributed to some nodes in the associated node set. For instance, if the threshold is 3, at least 3 nodes are needed to recover the key. Asynchronous verification involves nodes signing data locally using a portion of the key. The consortium blockchain network verifies data integrity by pulling a sufficient number of signatures. For example, production stage data requires signatures from raw material supply nodes, drug production nodes, and quality inspection nodes. If a node is offline, other nodes can supplement the signature. After successful verification, the data is stored in encrypted form in the blockchain ledger, and only authorized nodes can decrypt and view it through a permission contract.

[0030] In one possible implementation, multiple sets of associated circulation nodes, each associated with a different data on-chain stage, are extracted from the multiple circulation nodes. An asynchronous key splitting mechanism is used to perform encrypted joint verification on each of these sets. When the encrypted joint verification passes, the multiple sets of associated circulation nodes upload data to the blockchain for each data on-chain stage according to the multiple data permissions. Step S200 further includes step S210, extracting a first data on-chain stage from the multiple data on-chain stages and extracting a first set of associated circulation nodes from the multiple sets of associated circulation nodes. Specifically, one stage is selected from a pre-defined set of multiple data on-chain stages, such as raw material procurement, production, transportation, sales, and usage, as the first data on-chain stage. Here, "first" does not indicate order but simply refers to any one of the multiple stages. Simultaneously, the set of associated circulation nodes corresponding to the first data on-chain stage is extracted from the multiple sets of associated circulation nodes associated with each data on-chain stage; this first set of associated circulation nodes is the first set of associated circulation nodes. For example, if the first data uploading stage is the production stage, then the first set of associated circulation nodes includes raw material supply nodes and drug production nodes.

[0031] Step S220: The trusted hardware module based on the consortium blockchain network randomly generates a first master key. Specifically, the trusted hardware module based on the consortium blockchain network randomly generates a master key for encryption, referred to as the first master key. The trusted hardware module provides a secure environment to ensure that the generated key has high security and randomness.

[0032] Step S230: Obtain the number of nodes in the first associated flow node set, and combine this with the dynamic blank node generator to obtain the dynamic splitting quantity. Specifically, obtain the number of nodes in the first associated flow node set, i.e., the number of nodes participating in this data on-chain stage. Combine this with the dynamic blank node generator to dynamically determine the key splitting quantity. The dynamic blank node generator can flexibly adjust the splitting quantity according to actual conditions to enhance the system's adaptability and security.

[0033] Step S240: Based on the dynamically sharded number, the first master key is asynchronously sharded using an asynchronous key sharding mechanism to obtain a set of sharded subkeys. Specifically, based on the dynamically sharded number determined in step S230, the first master key is sharded using an asynchronous key sharding mechanism. Asynchronous key sharding refers to splitting the encryption key into multiple parts, that is, splitting the first master key into multiple subkeys to obtain a set of sharded subkeys. For example, using the Shamir secret sharing scheme, the master key is split into n parts.

[0034] Step S250: The segmented key set is randomly distributed to the first associated circulation node set through different channels for identity binding, thereby obtaining the first associated circulation node bound segmented key set. Specifically, the segmented key set is randomly distributed to each node in the first associated circulation node set through different channels, and the segmented key is bound to the node's identity. In this way, each node holds a portion of the segmented key, and the distribution through different channels reduces the risk of key leakage. Only legitimate nodes can obtain the corresponding segmented key.

[0035] Step S260: When the first data on-chain stage is triggered, the first set of associated circulation nodes can sign the data hash using an IoT chip, and perform encrypted joint verification in conjunction with the set of sharding keys bound to the first set of associated circulation nodes. Specifically, when the first data on-chain stage is triggered, the nodes in the first set of associated circulation nodes can perform hash calculations on the data to be uploaded to the chain using an Internet of Things (IoT) chip to obtain the hash value of the data. Then, each node signs the data hash according to its own bound sharding key to confirm the integrity of the data and the authenticity of its source.

[0036] Step S270: If the number of valid first-associative-transfer node bound sub-keys in the first-associative-transfer node bound sub-key set is greater than or equal to a preset threshold, the consortium blockchain network recovers the first master key through a threshold reconstruction algorithm, completing the encrypted joint verification. Specifically, the number of valid first-associative-transfer node bound sub-keys in the first-associative-transfer node bound sub-key set is checked. A valid sub-key refers to a key that can participate normally in the verification process and has not been tampered with or leaked. If the number of valid first-associative-transfer node bound sub-keys is greater than or equal to the preset threshold, it indicates that a sufficient number of legitimate nodes have participated in the verification process. At this time, the consortium blockchain network recovers the first master key through a threshold reconstruction algorithm. The threshold reconstruction algorithm can recover the original master key based on a portion of the sub-keys, thereby completing the encrypted joint verification. Only after verification can the first-associative-transfer node set perform the data on-chain operation in the first data on-chain stage according to the pre-configured multiple data permissions.

[0037] In one possible implementation, the number of nodes in the first associated flow node set is obtained, and combined with a dynamic blank node generator, the number of dynamic splits is obtained. Step S230 further includes step S231, obtaining a preset maximum number of blank nodes. Specifically, a maximum blank node threshold is preset, such as 10 or 20. This value is determined based on the balance between system security requirements and performance; too high a value may lead to an excessive number of splits, increasing computational overhead, while too low a value weakens randomness. The preset maximum number of blank nodes is used to provide an upper limit constraint for the generation of dynamic blank nodes, ensuring that the number of randomly generated blank nodes does not exceed the system's processing capacity.

[0038] Step S232: A first random number is randomly generated based on a dynamic blank node generator. This first random number is multiplied by a preset maximum number of blank nodes to obtain the dynamic number of blank nodes. Specifically, a random number in the range [0,1] is generated using a dynamic blank node generator, such as the Rand function. The random number is multiplied by a preset maximum value and rounded down to obtain the dynamic number of blank nodes. By introducing randomness, the number of blank nodes in each segment changes dynamically, preventing attackers from exploiting fixed patterns and improving the system's resistance to attacks.

[0039] Step S233: Add the number of dynamically empty nodes to the number of nodes in the first associated flow node set to obtain the dynamic segmentation number. Specifically, add the number of dynamically empty nodes to the actual number of nodes in the first associated flow node set to obtain the dynamic segmentation number. For example, if the associated node set has 5 nodes in a certain stage and the number of dynamically empty nodes is 3, then the dynamic segmentation number is 8. By randomly adding empty nodes, the complexity of key segmentation is increased, preventing the segmentation strategy from being deduced from the number of nodes.

[0040] In one possible implementation, based on the dynamically sharded quantity, the first master key is asynchronously sharded using an asynchronous key sharding mechanism to obtain a set of sharded subkeys. Step S240 further includes step S241, obtaining a set of historical sharded subkeys. Specifically, the set of historical sharded subkeys generated during previous key sharding operations is retrieved from storage. These historical sharded subkeys were generated in other data on-chain stages or related encryption scenarios and can be used as a reference to evaluate the reliability of the currently sharded subkeys. For example, the historical sharded subkey set contains multiple subkeys obtained from sharding at different data on-chain stages over a period of time, along with their related usage information.

[0041] Step S242: Retrieve the initial key splitting bandwidth in the asynchronous key splitting mechanism, perform the first split on the first master key, and verify the key reliability by combining it with the historical split subkey set. If the verification passes, obtain the first subkey and the first split master key. Specifically, retrieve the preset initial key splitting bandwidth in the asynchronous key splitting mechanism. This bandwidth is the length of the subkey obtained after dividing the first master key evenly according to the dynamic splitting number. For example, if the length of the first master key is 1024 bits and the dynamic splitting number is 4, then the initial key splitting bandwidth is 256 bits. Use the initial key splitting bandwidth to perform the first split on the first master key, obtaining a subkey (i.e., a candidate for the first split subkey) and the remaining part after splitting (i.e., the first split master key).

[0042] The subkeys obtained from the first split are compared and analyzed with the historical split subkey sets to verify key reliability. Verification metrics may include the randomness of the subkey, its similarity to historical keys, and whether it meets the requirements of a specific encryption algorithm. If the verification passes, the subkey is considered to have high reliability and is designated as the first split subkey. The first split master key is also retained for subsequent splits.

[0043] Step S243: If the verification fails, the initial key segmentation bandwidth is adjusted multiple times using a random adjustment method to obtain multiple adjusted key segmentation bandwidths. These multiple adjusted key segmentation bandwidths are then used to perform the first segmentation of the first master key, obtaining multiple adjusted sub-keys. The reliability of each of these adjusted sub-keys is then verified to obtain a first sub-key and a first segmented master key. Specifically, if the sub-key obtained from the first segmentation fails verification, the initial key segmentation bandwidth is adjusted randomly. The adjustment direction is to be less than the initial key segmentation bandwidth to ensure that the final number of segments after multiple adjustments meets the dynamic segmentation requirement. For example, if the initial key segmentation bandwidth is 256 bits, it can be adjusted to 200 bits, 180 bits, etc., during random adjustment. Multiple adjustments are performed to obtain multiple adjusted key segmentation bandwidths. Then, these multiple adjusted key segmentation bandwidths are used to perform the first segmentation of the first master key, obtaining multiple adjusted sub-keys. The reliability of each of these multiple adjusted sub-keys is then verified. During the verification process, multiple indicators are considered to select the first slicing key that meets the requirements and has the highest reliability as the first slicing key, and the corresponding first slicing master key is determined at the same time.

[0044] Step S244: The first segmented master key is segmented a second time according to the initial key segmentation bandwidth, and key reliability is verified by combining it with the historical segmented subkey set until the number of segmentations meets the dynamic segmentation quantity minus 1, thus obtaining the segmented subkey set. Specifically, the first segmented master key is segmented a second time according to the initial key segmentation bandwidth to obtain a new subkey (candidate) and the remaining part. The subkey obtained from the second segmentation is verified for key reliability with the historical segmented subkey set. The above second segmentation and verification process is repeated, with each segmentation generating a subkey, until the number of segmentations meets the dynamic segmentation quantity minus 1. The master key remaining after the last segmentation is directly used as the last subkey, finally obtaining a segmented subkey set containing multiple reliable subkeys.

[0045] In one possible implementation, the initial key splitting bandwidth of the asynchronous key splitting mechanism is retrieved, the first master key is split for the first time, and key reliability verification is performed in conjunction with the historical split sub-key set. If the verification passes, the first sub-key and the first split master key are obtained. Step S242 further includes step S2421, retrieving the initial key splitting bandwidth of the asynchronous key splitting mechanism, performing the first split on the first master key, and obtaining the first initial sub-key. Specifically, the obtained initial key splitting bandwidth is used to split the first master key, resulting in a sub-key, namely the first initial sub-key, and the remaining part of the master key after splitting.

[0046] Step S2422: Iterate through and calculate the matching similarity between the first initial segmentation key and the historical segmentation keys in the historical segmentation key set to obtain a matching similarity set. Specifically, each historical segmentation key in the historical segmentation key set is taken out sequentially, and for each taken historical segmentation key, the matching similarity is calculated with the first initial segmentation key. The matching similarity calculation method can adopt a variant of Hamming distance. Hamming distance refers to the number of different characters at the same position in two strings of equal length. Therefore, the matching similarity can be defined as (1 − Hamming distance / key length). Assuming the first initial segmentation key is 1010, a historical segmentation key is 1001, their Hamming distance is 2, and the key length is 4, then the matching similarity is 1 − 2 / 4 = 0.5. Record the matching similarity calculated between each historical segmentation key and the first initial segmentation key to form a matching similarity set.

[0047] Step S2423: Calculate the mean of the matching similarity set, and use the reciprocal of the calculation result as the key reliability coefficient. Specifically, calculate the average of all elements in the matching similarity set, and use the reciprocal of the mean of the matching similarity set as the key reliability coefficient. The reciprocal method is used to ensure that the key reliability coefficient has an inverse relationship with the overall situation of the matching similarity set; that is, the lower the matching similarity, the higher the key reliability coefficient.

[0048] Step S2424: Determine whether the key reliability coefficient is greater than or equal to a preset key reliability coefficient threshold. If so, the verification passes, and the first initial sub-key is used as the first sub-key, and the remaining part of the first master key after splitting is used as the first split master key. Specifically, the calculated key reliability coefficient is compared with the preset key reliability coefficient threshold. The preset key reliability coefficient threshold is a value set based on actual security requirements and experience. If the key reliability coefficient is greater than or equal to the preset key reliability coefficient threshold, it indicates that the difference between the first initial sub-key and the historical sub-key is large enough, and it has high reliability, so the verification passes. At this time, the first initial sub-key is determined as the first sub-key, and the remaining part of the master key after the first split is used as the first split master key for subsequent key splitting operations. If the key reliability coefficient is less than the preset key reliability coefficient threshold, it indicates that the first initial sub-key is too similar to the historical sub-key, posing a security risk, so the verification fails. At this time, the initial key splitting bandwidth is adjusted according to a random adjustment method, and the splitting and verification operations are repeated until a reliable sub-key is obtained.

[0049] In one possible implementation, when the cryptographic joint verification passes, multiple sets of associated circulation nodes perform multiple data uploading stages according to the multiple data permissions. Then, the method further includes: triggering a real-time verification instruction for a smart contract deployed on the consortium blockchain network; based on the real-time verification instruction, calling the IoT device signatures of the multiple sets of associated circulation nodes for signature verification, and performing integrity verification on the uploaded data to obtain multiple real-time verification results, wherein each real-time verification result includes a signature verification result and an integrity verification result; and implementing a penalty-reward mechanism for the multiple sets of associated circulation nodes based on the multiple real-time verification results.

[0050] Specifically, once the encrypted joint verification passes, the smart contract automatically deployed by the consortium blockchain network is activated, generating a real-time verification instruction. This instruction can be triggered based on a timestamp, event-driven mechanism, or external signal. It then invokes the digital signatures generated by the IoT devices of each node in the associated circulation node set. The smart contract verifies the signature validity using a preset public key, confirming the authenticity of the data source and its lack of tampering. For example, batch data uploaded by a raw material drug supply node must be accompanied by its IoT device signature; verification failure is marked as an anomaly. A hash verification is performed on the on-chain data, comparing the hash value stored on the blockchain with the recalculated hash value to detect whether the data has been tampered with during transmission or storage. Each node generates a binary result set containing signature verification results and integrity verification results. The signature verification result includes pass or fail, and the integrity verification result includes consistency or inconsistency. Nodes that pass multiple consecutive verifications are granted enhanced data permissions, improved credit scores, or economic rewards. For nodes that fail verification, tiered penalties are applied based on the severity. For example, if the severity is mild, a warning is issued, requiring the data to be resubmitted with additional verification; if the severity is moderate, privileges are temporarily reduced and a manual review process is initiated; if the severity is severe, the node is permanently removed, blacklisted, and publicly announced, affecting its eligibility to participate in the consortium blockchain in the future.

[0051] In one possible implementation, the penalty and reward mechanism further includes: when either the signature verification result or the integrity verification result fails, a preset reputation value is deducted from the associated circulation node, and the number of deductions is counted; when the number of deductions exceeds a preset deduction threshold, a penalty measure is triggered; when both the signature verification result and the integrity verification result pass, a preset reputation value is increased from the associated circulation node, and the number of increases is counted; when the number of increases exceeds a preset increase threshold, an incentive measure is triggered.

[0052] Specifically, upon joining the consortium blockchain, each associated circulation node is assigned an initial reputation value, such as 100 points, which is stored in a smart contract or on-chain reputation ledger. If either the signature verification or integrity verification fails (signature = failed or integrity = inconsistent), the associated circulation node's preset reputation value is deducted; a fixed value or a proportional deduction is made for each failure. Conversely, if both signature and integrity verifications pass (signature = passed and integrity = consistent), the associated circulation node's preset reputation value is increased; a fixed value or a proportional increase is made for each success.

[0053] A preset deduction threshold is set. If a node fails three times in a row and the cumulative number of deductions exceeds the preset threshold, penalty measures will be triggered, such as temporarily restricting data upload permissions, permanently removing the node and making it public, or freezing its on-chain assets, such as reputation collateral.

[0054] A preset threshold is set, such as 10 consecutive successful increases. If the cumulative number of increases for a node exceeds the preset threshold, incentive measures are triggered, such as priority participation in high-value data transactions or permission upgrades.

[0055] For nodes that have not participated in verification for an extended period, their reputation score decays over time, for example, by automatically deducting 1 point per month to prevent zombie nodes from consuming resources. Simultaneously, the threshold is dynamically adjusted based on the overall security situation of the consortium blockchain; for example, the preset deduction threshold is lowered during periods of high attack activity to strengthen control. All reputation score changes and reward / penalty records are written to the blockchain for monitoring by all nodes on the chain.

[0056] Step S300: When the target user scans the drug label through the terminal device, the consortium blockchain network performs data traceability of the entire drug lifecycle, and the drug usage data is uploaded to the blockchain through off-chain storage and on-chain indexing after feedback and review, thus completing the closed-loop traceability.

[0057] Specifically, after purchasing medication, the target user, i.e., the patient, scans the medication label using a terminal device, such as a mobile phone. This label is a unique identifier for the medication, and can use the GS1 standard or a custom code, binding the entire lifecycle data of the medication. The identifier is encoded as a QR code or embedded in an NFC chip, enabling the terminal device to scan and read it. After the target user scans the label, the terminal application calls the consortium blockchain node via API to query all on-chain data related to the medication from raw materials to the current stage. For example, a patient scans the QR code on the medication box to view the production date, transportation temperature record, and information about the pharmacy where it was sold.

[0058] Healthcare institution nodes submit patient medication data, such as prescriptions, efficacy, and adverse reactions, to the consortium blockchain. Regulatory or pharmaceutical company nodes verify the data's authenticity before adding it to the blockchain. Large files, such as CT images, are stored in a distributed file storage system or cloud storage; only the file hash value is stored on the blockchain as an index to save space.

[0059] This application's embodiments employ a consortium blockchain network built for the entire lifecycle of pharmaceuticals and the allocation of differentiated data permissions. An asynchronous key splitting mechanism is used to perform encrypted joint verification of the associated node sets at each stage of the process. After verification, data is uploaded to the blockchain in stages according to permissions. When users scan the code for traceability, the data is fed back. After review, the data is uploaded to the blockchain in a closed loop using a combination of off-chain storage and on-chain indexing. These technical means solve the technical problem of incompatibility between privacy protection and cross-stage trusted collaboration in existing trusted traceability of pharmaceutical lifecycle data, achieving the technical effect of both privacy protection and trusted cross-stage sharing.

[0060] In the above text, refer to Figure 1 This paper describes in detail a blockchain-based method for trusted traceability of pharmaceutical lifecycle data according to embodiments of the present invention. Next, reference will be made to... Figure 2This invention describes a blockchain-based trusted traceability system for the entire lifecycle of pharmaceutical data.

[0061] The blockchain-based trusted traceability system for pharmaceutical lifecycle data according to embodiments of the present invention addresses the technical problem of incompatibility between privacy protection and trusted cross-stage collaboration in existing trusted traceability systems for pharmaceutical lifecycle data, achieving the technical effects of both privacy protection and trusted cross-stage sharing. The blockchain-based trusted traceability system for pharmaceutical lifecycle data includes: a consortium blockchain network construction module 10, an encrypted joint verification module 20, and a traceability module 30.

[0062] The consortium blockchain network construction module 10 is used to build a consortium blockchain network, adding multiple circulation nodes throughout the entire lifecycle of the drug to the consortium blockchain network, and configuring multiple data permissions for each circulation node; the encrypted joint verification module 20 is used to extract multiple sets of associated circulation nodes related to multiple data on-chain stages from the multiple circulation nodes, and to perform encrypted joint verification on the multiple sets of associated circulation nodes through an asynchronous key splitting mechanism. When the encrypted joint verification passes, the multiple sets of associated circulation nodes upload data to the blockchain for multiple data on-chain stages according to the multiple data permissions; the traceability module 30 is used to trace the entire lifecycle of the drug through the consortium blockchain network when the target user scans the drug label through a terminal device, and to upload the drug usage data to the blockchain through off-chain storage and on-chain indexing after feedback review, thus completing closed-loop traceability.

[0063] The specific configuration of the consortium blockchain network construction module 10 is described in detail below: As mentioned above, the consortium blockchain network construction module 10 may further include: the multiple circulation nodes include raw material supply nodes, drug production nodes, warehousing and transportation nodes, wholesale and retail nodes, medical institution nodes and patient nodes.

[0064] The detailed description of the specific configuration of the encrypted joint verification module 20 is explained as follows: As mentioned above, multiple sets of associated transfer nodes related to multiple data on-chain stages are extracted from the multiple transfer nodes respectively. Encrypted joint verification is performed on the multiple sets of associated transfer nodes respectively through an asynchronous key splitting mechanism. When the encrypted joint verification passes, the multiple sets of associated transfer nodes perform data on-chain for multiple data on-chain stages according to the multiple data permissions. The encrypted joint verification module 20 may further include: a data extraction unit for extracting a first data on-chain stage from the multiple data on-chain stages and extracting a first set of associated transfer nodes from the multiple sets of associated transfer nodes; a first master key generation unit for randomly generating a first master key based on the trusted hardware module of the consortium blockchain network; and a dynamic splitting quantity acquisition unit for obtaining the number of nodes in the first set of associated transfer nodes and, in conjunction with a dynamic blank node generator, obtaining a dynamic splitting quantity. The system is divided into several parts: an asynchronous key splitting unit and an identity binding unit. The asynchronous key splitting unit performs asynchronous key splitting on the first master key based on the dynamic splitting quantity and an asynchronous key splitting mechanism to obtain a set of split sub-keys. The identity binding unit randomly distributes the set of split sub-keys to the first associated circulation node set through different channels for identity binding to obtain a set of first associated circulation node-bound split sub-keys. The cryptographic joint verification unit is used when the first data on-chain stage is triggered, the first associated circulation node set can sign the data hash through the IoT chip and perform cryptographic joint verification in combination with the set of first associated circulation node-bound split sub-keys. The first master key recovery unit is used when the number of valid first associated circulation node-bound split sub-keys in the set of first associated circulation node-bound split sub-keys is greater than or equal to a preset number threshold, the consortium blockchain network recovers the first master key through a threshold reconstruction algorithm to complete the cryptographic joint verification.

[0065] The first master key is asynchronously split based on the dynamic splitting quantity using an asynchronous key splitting mechanism to obtain a set of split sub-keys. The asynchronous key splitting unit may further include: a historical split sub-key set acquisition sub-unit for acquiring historical split sub-key sets; a key reliability verification sub-unit for retrieving the initial key splitting bandwidth in the asynchronous key splitting mechanism, performing a first split on the first master key, and verifying key reliability by combining the historical split sub-key set; if the verification passes, obtaining the first split sub-key and the first split master key; and a first split sub-key unit for, if the verification fails, then according to the following... The initial key splitting bandwidth is adjusted multiple times using a machine adjustment method to obtain multiple adjusted key splitting bandwidths. The first master key is then split for the first time using these multiple adjusted key splitting bandwidths to obtain multiple adjusted sub-keys. The reliability of each of these multiple adjusted sub-keys is verified to obtain a first sub-key and a first split master key. The second sub-key splitting unit is used to split the first split master key a second time according to the initial key splitting bandwidth, and the reliability of the first split master key is verified in conjunction with the historical sub-key set, until the number of splits meets the requirement of dynamic splitting quantity minus 1, thus obtaining the sub-key set.

[0066] The process includes: retrieving the initial key splitting bandwidth from the asynchronous key splitting mechanism; performing a first split on the first master key and verifying key reliability by combining it with a set of historical split sub-keys; if the verification passes, obtaining a first split sub-key and a first split master key; the key reliability verification sub-unit may further include: an initial key splitting bandwidth retrieval component for retrieving the initial key splitting bandwidth from the asynchronous key splitting mechanism, performing a first split on the first master key, and obtaining a first initial split sub-key; a matching similarity calculation component for iterating and calculating the matching similarity between the first initial split sub-key and the historical split sub-keys in the set of historical split sub-keys, and obtaining a matching similarity set; a key reliability coefficient acquisition component for calculating the mean of the matching similarity set, and using the reciprocal of the calculation result as the key reliability coefficient; and a judgment processing component for judging whether the key reliability coefficient is greater than or equal to a preset key reliability coefficient threshold. If so, the verification passes, the first initial split sub-key is used as the first split sub-key, and the remaining part after splitting the first master key is used as the first split master key.

[0067] Specifically, the method involves obtaining the number of nodes in the first associated flow node set and, in conjunction with a dynamic blank node generator, obtaining the dynamic segmentation number. The dynamic segmentation number acquisition unit may further include: a preset maximum blank node number acquisition subunit for obtaining a preset maximum blank node number; a dynamic blank node number acquisition subunit for randomly generating a first random number based on the dynamic blank node generator, multiplying the first random number by the preset maximum blank node number to obtain the dynamic blank node number; and a dynamic segmentation number acquisition subunit for adding the dynamic blank node number to the number of nodes in the first associated flow node set to obtain the dynamic segmentation number.

[0068] When the encrypted joint verification passes, multiple associated circulation node sets perform multiple data on-chain stages according to the multiple data permissions. Afterwards, the system may further include: a real-time verification instruction triggering module for triggering real-time verification instructions for smart contracts deployed on the consortium blockchain network; a real-time verification module for performing signature verification by calling the IoT device signatures of multiple associated circulation node sets based on the smart contract real-time verification instructions, and for performing integrity verification on the on-chain data to obtain multiple real-time verification results, wherein each real-time verification result includes a signature verification result and an integrity verification result; and a penalty and reward mechanism implementation module for implementing a penalty and reward mechanism for the multiple associated circulation node sets based on the multiple real-time verification results.

[0069] The penalty and reward mechanism implementation module may further include: a penalty triggering unit for deducting a preset reputation value from the associated circulation node when either the signature verification result or the integrity verification result fails, and counting the number of deductions; and triggering a penalty measure when the number of deductions exceeds a preset deduction threshold. An incentive triggering unit is used to increase the preset reputation value of the associated circulation node when both the signature verification result and the integrity verification result pass, and count the number of increases; and triggering an incentive measure when the number of increases exceeds a preset increase threshold.

[0070] The consortium blockchain network construction module 10 may further include: the consortium blockchain network adopts a Byzantine fault tolerance or proof-of-authority consensus mechanism to ensure data consistency among multiple circulation nodes.

[0071] The blockchain-based drug lifecycle data trusted traceability system provided in this embodiment of the invention can execute the blockchain-based drug lifecycle data trusted traceability method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0072] Although this application makes various references to certain modules in the system according to the embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy distinction between each other and are not used to limit the scope of protection of this invention.

[0073] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application. In some cases, the actions or steps described in this application can be performed in a different order than that shown in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A blockchain-based method for trusted traceability of pharmaceutical product lifecycle data, characterized in that, The method comprises: Constructing a consortium chain network, adding a plurality of circulation nodes in the whole life cycle of a medicine to the consortium chain network, and respectively configuring a plurality of data authorities for the plurality of circulation nodes; Extracting a plurality of associated circulation node sets associated with a plurality of data on-chain stages from the plurality of circulation nodes respectively, performing encryption joint verification on the plurality of associated circulation node sets respectively through an asynchronous key splitting mechanism, and when the encryption joint verification is passed, the plurality of associated circulation node sets perform data on-chain of the plurality of data on-chain stages according to the plurality of data authorities; When a target user scans a medicine identifier through a terminal device, performing data traceability of the whole life cycle of the medicine on the consortium chain network, and performing off-chain storage and on-chain indexing of the medicine use data after feedback auditing, and performing on-chain in a closed loop tracing manner; Wherein, extracting a plurality of associated circulation node sets associated with a plurality of data on-chain stages from the plurality of circulation nodes respectively, performing encryption joint verification on the plurality of associated circulation node sets respectively through an asynchronous key splitting mechanism, and when the encryption joint verification is passed, the plurality of associated circulation node sets perform data on-chain of the plurality of data on-chain stages according to the plurality of data authorities, comprising: Extracting a first data on-chain stage from the plurality of data on-chain stages, and extracting a first associated circulation node set from the plurality of associated circulation node sets; Randomly generating a first master key based on a trusted hardware module of the consortium chain network; Obtaining the number of nodes of the first associated circulation node set, and obtaining a dynamic splitting number by combining a dynamic blank node generator; According to the dynamic splitting number, performing asynchronous key splitting on the first master key based on an asynchronous key splitting mechanism to obtain a split sub-key set; Randomly distributing the split sub-key set to the first associated circulation node set through different channels for identity binding to obtain a first associated circulation node binding split sub-key set; When the first data on-chain stage is triggered, the first associated circulation node set signs the data hash through an IoT chip and performs encryption joint verification in combination with the first associated circulation node binding split sub-key set; If the number of valid first associated circulation node binding split sub-keys in the first associated circulation node binding split sub-key set is greater than or equal to a preset number threshold, the consortium chain network restores the first master key through a threshold reconstruction algorithm to complete the encryption joint verification; Wherein, according to the dynamic splitting number, performing asynchronous key splitting on the first master key based on an asynchronous key splitting mechanism to obtain a split sub-key set, comprising: Obtaining a historical split sub-key set; Accessing an initial key splitting bandwidth in the asynchronous key splitting mechanism, performing first splitting on the first master key, and performing key reliability verification in combination with the historical split sub-key set, if the verification is passed, obtaining a first split sub-key and a first split master key; If the verification fails, the initial key split bandwidth is adjusted multiple times in a random adjustment manner to obtain multiple adjusted key split bandwidths, the first master key is split for the first time using the multiple adjusted key split bandwidths to obtain multiple adjusted split sub-keys, the multiple adjusted split sub-keys are respectively subjected to key reliability verification to obtain a first split sub-key and a first split master key; The first split master key is split for the second time according to the initial key split bandwidth, and the key reliability verification is performed in combination with the historical split sub-key set until the split number satisfies the dynamic split number minus 1, and the split sub-key set is obtained. 2.The blockchain-based pharmaceutical product lifecycle data trusted traceability method of claim 1, wherein, The multiple flow transfer nodes include a bulk drug supply node, a drug production node, a warehousing and transportation node, a wholesale and retail node, a medical institution node, and a patient node. 3.The blockchain-based pharmaceutical product lifecycle data trusted traceability method of claim 1, wherein, The initial key split bandwidth in the asynchronous key split mechanism is called to split the first master key for the first time and perform key reliability verification in combination with a historical split sub-key set, and if the verification passes, a first split sub-key and a first split master key are obtained, including: The initial key split bandwidth in the asynchronous key split mechanism is called to split the first master key for the first time to obtain a first initial split sub-key. The matching similarity of the first initial split sub-key and the historical split sub-keys in the historical split sub-key set is calculated to obtain a matching similarity set. The mean of the matching similarity set is calculated, and the reciprocal of the calculation result is taken as a key reliability coefficient. It is judged whether the key reliability coefficient is greater than or equal to a preset key reliability coefficient threshold, and if yes, the verification passes, the first initial split sub-key is taken as a first split sub-key, and the remaining part after the first master key is split is taken as a first split master key. 4.The blockchain-based pharmaceutical product lifecycle data trusted traceability method of claim 1, wherein, The number of nodes of a first associated flow transfer node set is obtained, and a dynamic split number is obtained in combination with a dynamic blank node generator, including: A preset maximum blank node number is obtained. A first random number is randomly generated based on the dynamic blank node generator, the first random number is multiplied by the preset maximum blank node number to obtain a dynamic blank node number. The dynamic blank node number and the number of nodes of the first associated flow transfer node set are added to obtain a dynamic split number. 5.The blockchain-based pharmaceutical product lifecycle data trusted traceability method of claim 1, wherein, When the encryption joint verification passes, multiple associated flow transfer node sets perform data chaining in multiple data chaining stages according to the multiple data authorities, and then include: Triggering a smart contract deployed on the alliance chain network to perform real-time verification instructions; Based on the smart contract real-time verification instruction, calling the loT device signature of the multiple associated flow transfer node sets for signature verification and integrity verification of the chained data to obtain multiple real-time verification results, wherein each real-time verification result includes a signature verification result and an integrity verification result; Based on the multiple real-time verification results, the multiple associated flow transfer node sets are subjected to a punishment and reward mechanism. 6.The blockchain-based pharmaceutical product lifecycle data trusted traceability method of claim 5, wherein, The punishment and reward mechanism comprises: when any one of the signature verification result and the integrity verification result fails, a preset reputation value of the associated flow node is deducted, and the number of deductions is counted; when the number of deductions exceeds a preset deduction threshold, a punishment measure is triggered; When the signature verification result and the integrity verification result both pass, a preset reputation value of the associated flow node is increased, and the number of increases is counted; when the number of increases exceeds a preset increase threshold, an incentive measure is triggered. 7.The blockchain-based pharmaceutical product lifecycle data trusted traceability method of claim 1, wherein, The alliance chain network adopts a Byzantine fault tolerance or authority proof consensus mechanism to ensure data consistency of the plurality of flow nodes.

8. A blockchain-based pharmaceutical product lifecycle data trusted traceability system, characterized in that, The system is used to implement the blockchain-based pharmaceutical product whole life cycle data credible traceability method according to any one of claims 1-7, and the system comprises: An alliance chain network construction module is configured to construct an alliance chain network, add a plurality of flow nodes in a pharmaceutical product whole life cycle to the alliance chain network, and configure a plurality of data permissions for the plurality of flow nodes respectively; An encryption joint verification module is configured to extract a plurality of associated flow node sets associated with a plurality of data on-chain stages from the plurality of flow nodes respectively, perform encryption joint verification on the plurality of associated flow node sets respectively through an asynchronous key splitting mechanism, and when the encryption joint verification passes, the plurality of associated flow node sets perform data on-chain of the plurality of data on-chain stages according to the plurality of data permissions; A traceability module is configured to perform data tracing of a pharmaceutical product whole life cycle on the alliance chain network when a target user scans a pharmaceutical product identifier through a terminal device, and perform chain off-storage and chain on-indexing of the pharmaceutical product use data after feedback auditing, to complete closed-loop tracing.

Images