Blockchain-based medicine logistics full-chain credible traceability method

Abstract

This invention relates to a blockchain-based trusted traceability method for the entire pharmaceutical logistics chain, aiming to solve the technical challenges of automatic performance data collection, continuous identity authentication, and dynamic migration of heterogeneous nodes. Its core solution includes: low-overhead detection of node hardware encryption capabilities, memory latency, and storage throughput performance through the distribution of lightweight probe packets, generating node capability fingerprints; constructing a spatiotemporal entropy source using drug batch information, UTC timestamps, and BeiDou timing deviations as a key derivation dynamic salt value; iteratively generating drug-specific keys and decentralized identity identifiers using a trusted execution environment; and implicitly anchoring node capability fingerprints and drug identities through on-chain registration; when node devices change, identity migration or triggering minimal re-authentication is determined based on the fingerprint drift editing distance, ensuring the continuity and security of identity binding. This technology can efficiently support heterogeneous device performance identification and dynamic maintenance of trusted identities in blockchain-based pharmaceutical distribution scenarios.

Description

Technical Field

[0001] This invention relates to the field of blockchain-based pharmaceutical logistics data storage traceability and digital identity management technology, and in particular to a blockchain-based trusted traceability method for the entire pharmaceutical logistics chain. Background Technology

[0002] Currently, in the fields of trusted data storage and traceability across the entire pharmaceutical logistics chain and digital identity management for pharmaceuticals, the widespread application of blockchain technology has made the on-chain storage of pharmaceutical information throughout the entire process and trusted collaboration among multiple nodes the mainstream direction in the industry. Most mainstream blockchain-based pharmaceutical traceability solutions adopt consortium blockchains or permissioned blockchain architectures, generating unique digital identities for pharmaceuticals to achieve full lifecycle traceability from production, warehousing, transportation to final retail. Existing technologies typically utilize digital certificates, distributed identity (DID), or centralized authentication services to register ownership and authorize actions for various participating nodes (such as logistics companies, warehousing facilities, and hospital pharmacies), thereby ensuring the authenticity and immutability of the information on the chain. In recent years, the standardized generation of pharmaceutical identity identifiers and the binding of node information have led to multiple implementation routes based on public key infrastructure (PKI), trusted IoT terminals, and standard DID frameworks, continuously improving the standardization, security, and scalability of pharmaceutical traceability systems.

[0003] However, most existing technical solutions for generating and binding digital identities for pharmaceuticals to nodes face the following prominent problems: First, the binding method between node identities and pharmaceutical digital identities is relatively static. It is usually forcibly completed through a centralized registry or DID template during node admission or registration. Later, if nodes undergo hardware upgrades, network topology changes, or heterogeneous nodes dynamically join or leave, the original identity binding relationship is difficult to flexibly migrate or adjust, making it difficult to adapt to the highly dynamic environment of pharmaceutical logistics. Second, nodes in consortium blockchains are highly heterogeneous, with significant differences in hardware resources, encryption capabilities, and computing performance. Existing generation mechanisms based on fixed identity templates cannot adapt to the characteristics of node capabilities, leading to limitations such as fragmentation, invalidation, or difficulty in unified verification across the entire network for pharmaceutical digital identities. Third, to ensure identity security and reliable end-to-end traceability, some solutions introduce zero-knowledge proofs, threshold cryptography, or complex key management mechanisms. However, these mechanisms have high computational and storage overhead, making them difficult to promote in a large number of resource-constrained edge devices (such as cold chain sensors and vehicle-mounted PDAs). Furthermore, centralized registration or revocation processes increase the operational burden, and once the master node fails, the system's elasticity and availability decrease significantly. Fourth, many traditional solutions lack fingerprint-level identification and seamless migration mechanisms when handling node hardware changes or dynamic management of consortium blockchains. This can easily lead to loss of drug identity and interruption of verification, thereby affecting the continuity of the entire chain traceability and the credibility of terminal verification. Summary of the Invention

[0004] This application provides a blockchain-based method for trusted traceability of the entire pharmaceutical logistics chain, aiming to solve one of the problems or issues of the existing technology mentioned in the background section.

[0005] This application provides a blockchain-based method for trusted traceability across the entire pharmaceutical logistics chain, specifically including: S1: Send a lightweight probe packet to the logistics node to be connected to the consortium blockchain, triggering the node to perform local resource detection and obtain the node's original hardware resource data; S2: Based on the original hardware resource data, perform standardized encoding processing, and concatenate the encoding result with the hash of the unified social credit code suffix of the enterprise to which the node belongs to generate the node capability fingerprint; S3: The drug batch information is fused with the UTC microsecond-level timestamp broadcast by the regulatory platform and the Beidou time synchronization deviation compensation value to construct a spatiotemporal entropy source; S4: Utilize a trusted execution environment to initiate a distributed key derivation protocol, using the node capability fingerprint as the root key and the spatiotemporal entropy source as the salt value to perform multiple rounds of lightweight hash iterations, generate a drug-specific private key and simultaneously derive a decentralized digital identity identifier. S5: Perform a hash operation on the node capability fingerprint to generate an anchor hash value, and write the anchor hash value into an on-chain registration transaction containing the decentralized digital identity identifier; S6: When a change in a node device is detected, resulting in the generation of a new node capability fingerprint, the Hamming distance between the new node capability fingerprint and the node capability fingerprint corresponding to the original anchor hash value is calculated, and an edit distance value is generated. S7: If the edit distance value is less than or equal to the preset tolerance threshold, then update the anchor hash value stored in the on-chain registered transaction; S8: If the edit distance value is greater than the preset tolerance threshold, the minimized re-authentication process is triggered and the new anchor point registration in the on-chain registration transaction is completed.

[0006] This application provides a blockchain-based, end-to-end trusted traceability method for pharmaceutical logistics, which has the following beneficial effects: (1) To address the technical bottleneck of existing drug traceability systems in heterogeneous network environments where it is difficult to balance security strength and terminal adaptability flexibility, this solution constructs a dynamic modeling mechanism of "node capability fingerprints" to achieve lightweight and non-intrusive perception of the computational and encryption capabilities of diverse logistics nodes (such as cold chain vehicle terminals, edge gateways, RFID readers, etc.) in the consortium blockchain. Compared with the traditional approach that relies on fixed identity templates or centralized configuration tables, this solution uses low-overhead probe packets to trigger the detection of three key local indicators—encryption instruction set availability, memory response jitter, and non-volatile storage write throughput—and encodes them into standardized strings. Combined with the enterprise credit code hash, a unique fingerprint is generated, effectively avoiding identity generation failures or verification deviations caused by differences in device resources. This design significantly improves the initialization success rate and environmental adaptability of drug digital identities in complex access scenarios, and is especially suitable for applications in pharmaceutical logistics where there are a large number of terminals with performance fluctuations or limited resources. It greatly reduces the deployment threshold and enhances the robustness of the system.

[0007] (2) By introducing the three-in-one identity generation and binding logic of "spatiotemporal entropy injection - collaborative derivation - implicit anchoring", this scheme breaks through the limitations of the traditional blockchain identity system in dynamic environments, such as single key derivation, unverifiable source, and high update cost. Using highly uncertain national time data and microsecond-level timestamps as entropy sources, it ensures that each identity generation process has strong randomness and anti-replay capability; based on the TEE environment, it executes multiple rounds of lightweight hash iteration with node capability fingerprint as the root and spatiotemporal entropy as the salt to realize the secure derivation of private keys and ensure the unforgeability of drug-specific identities; at the same time, it adopts a four-segment PDID encoding structure to achieve the purpose of globally unique identification and traceable source characteristics without relying on the W3C DID standard; more importantly, by embedding the fingerprint hash value as metadata into the on-chain registration transaction instead of storing the original information in plaintext, it realizes the "implicit anchoring" of identity and node capability. Any verifier can complete the validity verification through local reconstruction and comparison without calling smart contracts or accessing external databases, which greatly reduces on-chain interaction overhead and verification latency, and significantly improves the overall operating efficiency and decentralization of the system.

[0008] (3) Furthermore, this solution innovatively proposes a "dynamic decoupling" mechanism to address the challenge of identity persistence brought about by the evolution of node capabilities. This effectively overcomes the problems of existing solutions requiring the re-registration of all identities after equipment upgrades or replacements, which are cumbersome and cause service interruptions. When a node fingerprint changes, the system automatically initiates "fingerprint drift verification," determining whether direct updating of the anchor hash is allowed based on the edit distance tolerance, thus achieving seamless connection. For cases exceeding the tolerance, only the header hash and signature of the three most recent participating blocks are required. The on-chain lightweight module verifies the continuity of its historical behavior and approves the registration of the new anchor point. The entire process does not require repeating the complete authentication process, nor does it rely on a third-party credential issuing authority. This mechanism greatly simplifies the complexity of operation and maintenance while ensuring security, supports the elastic maintenance of drug digital identities throughout their lifecycle, and effectively meets the actual needs of long pharmaceutical logistics chains and frequent node changes. In summary, this solution constructs a dynamic adaptation system for drug digital identities that is adaptable, low-overhead, and highly reliable in resource-constrained environments. It not only strengthens the integrity and tamper-proof capabilities of the entire data traceability chain, but also provides a replicable and easily scalable technical paradigm for efficient collaboration of large-scale heterogeneous terminals in consortium blockchains. Attached Figure Description

[0009] Figure 1 This is the main flowchart of a blockchain-based, fully trusted traceability method for pharmaceutical logistics. Figure 2 This is a sub-flowchart of a blockchain-based, fully trusted traceability method for pharmaceutical logistics. Figure 3 This is another sub-flowchart of a blockchain-based, fully trusted traceability method for pharmaceutical logistics. Figure 4 This is an application environment diagram of a blockchain-based trusted traceability method for the entire pharmaceutical logistics chain, as illustrated in one embodiment. Figure 5 This is a schematic diagram of the structure of a computer device provided in one embodiment of this application. Detailed Implementation

[0010] Embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0011] The following disclosure provides many different embodiments or examples for implementing different structures of the invention. To simplify the disclosure, specific examples of components and arrangements are described below. Of course, these are merely examples and are not intended to limit the invention. Furthermore, reference numerals and / or letters may be repeated in different examples; such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0012] like Figure 1 As shown, this application provides a blockchain-based method for trusted traceability across the entire pharmaceutical logistics chain, specifically including: S1: Send a lightweight probe packet to the logistics node to be connected to the consortium blockchain, triggering the node to perform local resource detection and obtain the node's original hardware resource data.

[0013] Specifically, the original hardware resource data includes, but is not limited to: encryption algorithm support types, millisecond-level jitter range levels, and three-level encoded storage throughput capabilities; the trigger node performs local resource detection, including at least one of the following detection tasks: performing encryption instruction set availability scanning, memory page allocation response latency sampling, and local non-volatile storage random write throughput estimation.

[0014] S2: Based on the original hardware resource data, perform standardized encoding processing, and concatenate the encoding result with the hash of the unified social credit code suffix of the enterprise to which the node belongs to generate a node capability fingerprint. The node capability fingerprint is used to characterize the heterogeneous performance features of the node.

[0015] S3: The batch information of drugs is fused with the UTC microsecond-level timestamp broadcast by the regulatory platform and the Beidou time synchronization deviation compensation value to construct a spatiotemporal entropy source containing unpredictable randomness, which serves as the dynamic salt value input for subsequent key derivation.

[0016] S4: Utilize a trusted execution environment to initiate a distributed key derivation protocol, using the node capability fingerprint as the root key and the spatiotemporal entropy source as the salt value to perform multiple rounds of lightweight hash iterations, generating a drug-specific private key and simultaneously deriving a decentralized digital identity identifier conforming to a four-segment encoding structure.

[0017] S5: Perform a SHA3-256 hash operation on the node capability fingerprint to generate an anchor hash value, and write the anchor hash value as a metadata field into the on-chain registration transaction containing the decentralized digital identity identifier, thereby completing the implicit anchoring of node capability and drug identity.

[0018] S6: When a node device change is detected, resulting in a new node capability fingerprint, calculate the Hamming distance between the new node capability fingerprint and the node capability fingerprint corresponding to the original anchor hash value, and generate an edit distance value that characterizes the degree of fingerprint drift.

[0019] S7: Determine whether the edit distance value is less than or equal to a preset tolerance threshold. If the edit distance value is less than or equal to the preset tolerance threshold, directly update the anchor hash value stored in the on-chain registration transaction to achieve seamless migration of identity binding relationship.

[0020] S8: If the edit distance value is greater than the preset tolerance threshold, then the minimized re-authentication process is triggered and the new anchor point registration in the on-chain registration transaction is completed. Specifically, triggering the minimized re-authentication process and completing the new anchor point registration in the on-chain registration transaction includes: based on the hash and signature of the three most recent successful participating blocks submitted by the receiving node in the minimized re-authentication process, the new anchor point registration is approved after the on-chain lightweight verification module confirms the continuity of historical behavior, thus completing the dynamic decoupling and reconstruction of the drug digital identity in a heterogeneous node environment.

[0021] Step S1: Send a lightweight probe packet to the logistics node to be connected to the consortium blockchain, triggering the node to perform three low-overhead detection tasks locally: encryption instruction set availability scan, memory page allocation response latency sampling, and local non-volatile storage random write throughput estimation. This obtains raw hardware resource data including the types of encryption algorithms supported, millisecond-level jitter range, and three-level encoded storage throughput capabilities. Specifically, this includes: S1.1: Perform protocol parsing on the lightweight probe packets sent by the consortium blockchain access gateway to extract task configuration parameters including encrypted instruction set scan identifier, memory latency sampling threshold and storage throughput estimation level, and generate a standardized detection instruction sequence for triggering node local self-testing.

[0022] The input condition is a lightweight probe packet generated and issued by the consortium blockchain access gateway. This probe packet contains task identifiers and threshold setting data required for node hardware self-testing, including encrypted instruction set scan identifiers, memory latency sampling thresholds, and storage throughput estimation levels, all of which are encapsulated in the payload area of ​​the data packet according to the protocol specifications.

[0023] The protocol header of the lightweight probe packet is parsed, and the version field and message type field are identified using a pre-defined message structure description file, and the corresponding data offset is extracted.

[0024] Based on the offset, the task identifier index table of the payload area is read, and the encrypted instruction set scan identifier code is matched with the operation type mapping table in the protocol according to the index table order. The identified scan identifier is then matched with the subsequent execution environment call parameters.

[0025] The parameter decoding module is invoked to read the memory latency sampling threshold field in the payload in a fixed length and perform unit conversion to map the threshold parameter in microseconds to millisecond-level floating-point representation in order to be compatible with the sampling accuracy of the node self-test module.

[0026] The storage throughput estimation level field is parsed by enumeration, and the integer level value is mapped to the write task strength parameter in the node non-volatile storage module test process according to the three-level performance coding defined by the protocol.

[0027] The task configuration parameters, after the above parsing, mapping, and unit conversion processes, are summarized into structured instruction objects and arranged in a fixed order to form a standardized sequence of detection instructions for triggering local self-checks of nodes.

[0028] Through the above protocol parsing and processing, the original probe packet from the previous step is transformed into a standardized sequence of detection instructions that can be directly executed on the node side, thereby enabling heterogeneous nodes to achieve a hardware resource self-check and preparation state under a unified instruction format.

[0029] S1.2: Based on the standardized detection instruction sequence, perform an encryption instruction set availability scan on the central processing unit of the logistics node to be connected, so as to identify the national cryptographic algorithm or internationally common algorithm type supported by the node hardware, and generate an encryption algorithm support type code that characterizes the cryptographic computing power of the node.

[0030] Upon receiving the standardized detection instruction sequence generated from the preceding steps, the hardware characteristic query interface is invoked for the central processing unit (CPU) of the logistics node to be connected, loading task configuration data containing the encryption instruction set scanning identifier into the instruction execution buffer. Relying on the CPU's instruction set identification unit, specific instruction sequences are triggered based on the national cryptographic algorithm enumeration table and the internationally recognized algorithm support matrix to detect the hardware-level support status of instruction sets such as SM2, SM4, RSA, and ECC, and record the corresponding return opcodes. The return opcodes of each detection operation are mapped bitwise in the buffer according to the instruction type order to construct a preliminary encryption support status bitmap. Integrity checks are performed on the bitmap results to eliminate abnormal responses during the detection process. An encoding mapping table is used to convert the support status bitmap into a fixed-length encryption algorithm support type encoding string. This encoding includes category identifier bits for supported algorithms and null value identifier bits for unsupported algorithms, ensuring consistency in subsequent data concatenation through a fixed field length. A hash digest is calculated on the generated encryption algorithm support type encoding to form a cryptographic computing power feature digest value that can be used in subsequent steps, providing execution context for memory latency sampling and storage throughput estimation. By scanning the availability of hardware instruction sets, the results of the previous step are transformed into encryption algorithm support type encodings that characterize the cryptographic computing power of nodes, thereby achieving accurate quantification and standardized output of node encryption capabilities.

[0031] S1.3: Using the encryption algorithm to support type encoding as the execution context, initiate a memory page allocation response delay sampling operation on the node's random access memory to measure the millisecond-level time jitter range and map it to a preset performance level, generating millisecond-level jitter range level data that characterizes the node's real-time computing response capability.

[0032] For the encryption algorithm support type encoding output by the preceding sub-step S1.2, an execution context is established, and the encoding is loaded into the memory latency sampling logic unit of the node detection module to limit the instruction set and arithmetic operation mode called during the detection process.

[0033] An allocation request is initiated at the page allocation management layer of the random access memory, using a standardized test page size configuration (e.g., 4KB) and periodic allocation / reclaim instructions are called. The time interval from each allocation operation to its completion and return is recorded to form the original latency measurement sequence.

[0034] The jitter range statistical processing is performed on the original delay measurement sequence. The delay fluctuation amplitude Δt is obtained by calculating the difference between the maximum delay and the minimum delay. Then, Δt is mapped to the preset performance level threshold and the continuous time value is divided into numbered levels.

[0035] The following formula is used to calculate the statistical range of time delay during jitter amplitude calculation: Where t max t is the maximum delay in the sampled sequence. min Δt represents the minimum delay in the sampling sequence, and Δt represents the jitter range.

[0036] The performance tier number generated by the mapping is associated with the type encoding supported by the encryption algorithm and stored to generate millisecond-level jitter range tier data that characterizes the real-time computing response capability of the node.

[0037] Through the above processing method, the encryption algorithm support type encoding of the previous step is transformed into quantifiable memory response performance data, thereby achieving a standardized representation of the node's computing response capability.

[0038] S1.4: Perform a local random write throughput estimation test on the node's non-volatile storage module based on the millisecond-level jitter range data. Perform three-level quantization encoding based on the megabytes written per unit time to generate a three-level encoded storage throughput value that characterizes the node's persistent data write performance.

[0039] S1.5: The encryption algorithm supports type encoding, millisecond-level jitter range data and three-level encoding storage throughput value are structured and encapsulated to form an original hardware resource data packet containing multi-dimensional hardware resource characteristics, thereby completing the comprehensive collection and aggregation of the underlying data of heterogeneous node performance.

[0040] Step S2: Based on the original hardware resource data, perform standardized encoding processing, and concatenate the encoding result with the hash of the unified social credit code suffix of the enterprise to which the node belongs to generate a node capability fingerprint for characterizing the heterogeneous performance characteristics of the node. Specifically, this includes: S2.1: Discretize the encryption instruction set availability scan results in the original hardware resource data, and convert the identified encryption module types into fixed-length binary bitmap codes based on a preset algorithm support level table to generate encryption capability encoding vectors that characterize the cryptographic computing power features of the nodes.

[0041] The system performs data parsing on the availability scan results of the encryption instruction set contained in the original hardware resource data package, extracts the identification code of the encryption module type supported by the hardware, and uses it as the input object for discretization mapping.

[0042] Based on a pre-set algorithm support level table, the above-mentioned identification codes are mapped to the corresponding level index values ​​according to different combination modes of national cryptographic algorithms (SM2, SM4, SM9, etc.) and internationally used algorithms (RSA, ECC, AES, etc.), and the cryptographic computing power group position is determined by the level index.

[0043] Perform a binary bitmap encoding conversion operation on the level index value, and assign an independent bit order to each algorithm support state according to the fixed-length encoding rule, marking the support state as 1 and the non-support state as 0.

[0044] In the bitmap encoding conversion process, when multiple algorithms are supported simultaneously, the bit order sorted by priority is used for superposition and marking to ensure that the encoding structure is unique and reversible.

[0045] The generated fixed-length binary bitmap is structured and arranged to form a cryptographic capability encoding vector that represents the cryptographic computing power characteristics of the node, which is then used as the input for the memory response bit encoding quantization in the subsequent sub-step S2.2.

[0046] By using discretization mapping and fixed-length bitmap encoding, the encryption algorithm support type encoding of the previous step is transformed into an encryption capability encoding vector that can be directly used to construct hardware performance benchmarks, thereby achieving a precise and structured representation of the node's cryptographic computing power.

[0047] S2.2: Based on the encryption capability encoding vector, the memory page allocation response delay sample value in the original hardware resource data is subjected to interval quantization processing. The continuous delay time is divided into preset performance level numbers using the millisecond-level jitter range threshold, so as to generate a memory response level code that characterizes the memory throughput stability of the node.

[0048] S2.3: Using the memory response level code, the estimated local non-volatile storage random write throughput in the original hardware resource data is subjected to hierarchical normalization processing. Based on the integer mapping rule of megabytes per second transmission rate, a three-level throughput level code is generated to generate a storage throughput level code that characterizes the node's persistent storage efficiency.

[0049] S2.4: Perform a serial concatenation operation on the encryption capability encoding vector, memory response level encoding, and storage throughput level encoding, and construct a structured string containing multi-dimensional hardware features according to a fixed byte length alignment rule to generate a node hardware feature composite code that represents the node's full-dimensional heterogeneous performance benchmark.

[0050] Based on the fixed-length numerical inputs of the completed encryption capability encoding vector, memory response level encoding, and storage throughput level encoding, this sub-step performs a serial concatenation operation to construct the node hardware feature composite code. A byte order reordering algorithm is applied to the encryption capability encoding vector, adjusting its order according to the rule of high-order bits first and low-order bits last, to ensure consistency in cross-platform environments. Bit-width expansion processing is performed on the byte-order reordered encryption capability encoding vector and memory response level encoding, padding the memory response level encoding to a fixed byte length to form a homogeneous data block that can be directly concatenated. Unsigned integer formatting is applied to the above two data blocks, converting each field into a unified binary representation, and arranging them sequentially in the target buffer according to a preset concatenation order. A fixed-length append operation is performed on the two existing data segments in the concatenation buffer and the storage throughput level encoding to ensure that the overall structure string length remains constant. A byte alignment padding algorithm is applied to the formed complete data structure, inserting a preset number of padding zeros or specific mask bits between each field to satisfy the fixed byte length alignment rule and enhance anti-parsing ambiguity. Through the above processing method, the result of the previous step is transformed into a node hardware feature composite code that contains multi-dimensional hardware features and can uniquely identify the heterogeneous performance benchmark of nodes in the consortium blockchain environment, thus realizing a solid data foundation for subsequent enterprise credit hash fusion.

[0051] S2.5: Based on the node hardware feature composite code, extract the suffix field of the unified social credit code of the enterprise to which the node belongs and perform a one-way hash operation to generate an enterprise identity digest. Then, perform a secondary fusion and splicing of the enterprise identity digest and the node hardware feature composite code to generate a node capability fingerprint that combines the differences in equipment performance with the uniqueness of enterprise affiliation.

[0052] The input conditions include the generated node hardware feature composite code string and the complete field of the unified social credit code of the enterprise to which the node belongs. Based on the node hardware feature composite code, the string processing module is called to extract the suffix of the unified social credit code, making its length meet the preset hash algorithm input requirements. The extracted result is used as the enterprise identity source data. A one-way hash operation is performed on the enterprise identity source data, using a secure hash function with collision resistance. The enterprise identity digest is generated through bit permutation, shifting, and modulo addition operations to ensure that the enterprise identification information cannot be deduced from the digest. The enterprise identity digest and the node hardware feature composite code are byte sequence fused. The two are concatenated into a new composite data block according to the preset fixed byte length concatenation rules, maintaining structural integrity and extensibility. The format of the fused composite data block is standardized to eliminate cross-platform encoding differences and ensure consistent length, resulting in a node capability fingerprint with device performance differences and unique enterprise affiliation. Through a two-factor fusion concatenation processing method, the composite code and enterprise identity digest from the previous step are transformed into a node capability fingerprint, achieving a high-strength binding effect between the performance characteristics of heterogeneous nodes and enterprise identities in the consortium blockchain.

[0053] like Figure 2 As shown, step S3 involves fusing the drug batch information with the UTC microsecond-level timestamp broadcast by the regulatory platform and the BeiDou time synchronization deviation compensation value to construct a spatiotemporal entropy source containing unpredictable randomness, which serves as the dynamic salt value input for subsequent key derivation. Specifically, this includes: S3.1: Perform standardized serialization encoding on the batch information of drugs in the drug delivery process, extract the key field sequence containing the national drug approval number, production date stamp and expiration date, and generate a basic batch feature vector to represent the inherent attributes of the drug, which serves as the static input basis for the construction of the spatiotemporal entropy source.

[0054] In this specific embodiment, the drug batch information specifically refers to a set of core data fields collected and structured during the drug outbound process to uniquely identify and trace the batch of products. This drug batch information includes, but is not limited to: a unique drug identifier such as a drug electronic supervision code or the internationally recognized GTIN, production batch number, production date, expiration date, quantity shipped this time, and destination information such as the target warehouse or medical institution code. This information collectively constitutes a complete data snapshot of the batch of drugs at the outbound node. It is the lowest-level data element used to achieve reliable traceability across the entire chain, and is ultimately bound to subsequent standardized serialization encoding, the generation of basic batch feature vectors, and high-precision timestamps.

[0055] S3.2: Based on the basic batch feature vector, access the broadcast interface of the supervision platform to obtain UTC microsecond-level timestamp data, and perform nanosecond-level jitter filtering on the UTC microsecond-level timestamp data to generate calibration time reference parameters with monotonically increasing characteristics and eliminating network transmission delay errors.

[0056] Based on the aforementioned basic batch feature vector, a real-time receiving channel for high-precision UTC microsecond-level timestamp data is established by calling the broadcast interface of the regulatory platform, ensuring that the time data source is authoritative and has network-wide synchronization characteristics. During the reception process, the broadcast signal undergoes data frame parsing processing to extract the microsecond and second components of the UTC timestamp field, and these components are combined to form a complete high-precision time representation. A nanosecond-level jitter filtering algorithm is used to denoise the time representation. By detecting the rate of change between consecutive time frames, abnormal fluctuation values ​​exceeding a preset jitter threshold are eliminated to remove short-period interference introduced by network transmission delay. A time series smoother is used to perform monotonically increasing correction on the jitter-free time data, adjusting any possible backtracking or stalled time slices into an increasing sequence to ensure the continuity of the time reference. The final corrected time value is mapped to a unified time reference format, and calibration time reference parameters with nanosecond-level stability and authoritative synchronization source are output. By using the above-mentioned filtering, denoising, and monotonicity correction methods, the basic batch feature vectors from the previous step are fused with high-precision time data to form a dynamic time reference that can directly participate in the construction of the spatiotemporal entropy source, thereby achieving the consistent goal of eliminating delay errors and improving system time accuracy.

[0057] For example, in a cold chain logistics scenario for biological products, the basic batch feature vector includes the national drug approval number "H20020210", the production date timestamp 1617235200, and the expiration date timestamp 1679808000. The UTC microsecond-level timestamp broadcast by the regulatory platform consists of a whole second portion of 1640995200 and a microsecond portion of 452187. The complete time 1640995200.452187 seconds is obtained through parsing. The nanosecond-level jitter filtering threshold is set to 50 nanoseconds. The time differences between three consecutive broadcast frames are detected to be 45, 60, and 42 nanoseconds, respectively. The 60-nanosecond difference exceeds the threshold and is therefore considered abnormal and removed. The smoother adjusts the time series according to a monotonically increasing rule to 1640995200.452187, 1640995200.452232, and 1640995200.452274 seconds, outputting a calibration time base parameter of 1640995200.452274 seconds. This time base is combined with the basic batch feature vector in subsequent spatiotemporal entropy source calculations, and after single-round hash compression using the national cryptographic SM3 standard, a dynamic salt value input is generated, effectively improving the time synchronization accuracy of drug digital identity generation and the system's anti-interference capability.

[0058] S3.3: Receive the original satellite timing signal using the BeiDou satellite navigation system timing service interface, calculate the clock deviation value between the original satellite timing signal and the calibration time reference parameter, and generate a BeiDou timing deviation compensation value that characterizes the time synchronization accuracy of the current geographical area, so as to introduce random disturbance factors from external astrophysical sources.

[0059] S3.4: Perform multi-dimensional splicing and fusion processing on the basic batch feature vector, the calibration time reference parameters and the BeiDou time synchronization deviation compensation value, and perform a single-round hash compression operation based on the national cryptographic SM3 algorithm to generate an initial fusion summary data block containing static drug attributes and dynamic spatiotemporal disturbance information.

[0060] In this sub-step, the calibration time reference parameters output from S3.3, the BeiDou timing deviation compensation value, and the basic batch feature vector formed in S3.1 are used as input objects. First, uniform byte order alignment and data type forced conversion processing are performed on the three types of input data. The national drug approval number, production date stamp, and expiration date fields contained in the structured batch feature vector are converted into fixed-length byte streams. The calibration time reference parameters and BeiDou timing deviation compensation values ​​are converted into double-precision floating-point format and encoded into standard byte streams to ensure the length consistency and type compatibility of subsequent fusion operations.

[0061] A multi-dimensional splicing operation is performed on three types of data that have been normalized in terms of type and length. In the preset splicing sequence, the basic batch feature vector is used as the first segment, the calibration time reference parameter is used as the middle segment, and the Beidou time synchronization deviation compensation value is used as the last segment. The data segments are connected in byte order to form a high-dimensional fusion input sequence. This sequence has the comprehensive characteristics of simultaneously containing static drug attributes and dynamic spatiotemporal disturbance information.

[0062] The high-dimensional fused input sequence is subjected to a single-round hash compression operation based on the national cryptographic SM3 algorithm. First, the fused sequence is divided into 512-bit message blocks. For each block, a message expansion step is performed to generate 68 words. The iterative compression function of the SM3 algorithm is used to perform bit permutation, modular addition, circular right shift, and XOR operation. One iteration of compression processing is completed on the internal chain value variable to ensure that the output digest has cryptographic collision resistance and irreversibility.

[0063] The following formula is used to perform a hash operation on the fused sequence: Where BatchVec is the batch feature vector byte stream, TimeCal is the calibration time reference byte stream, BDSync is the BeiDou time synchronization deviation compensation value byte stream, ∥ indicates the sequential concatenation operation, and SM3 is the national cryptographic SM3 hash function.

[0064] The output of the above hash operation is solidified into a fixed-length summary data block as the output of this sub-step. The feature information encoded in the summary data block contains both static drug attribute features and dynamic spatiotemporal perturbation randomness. Through hash compression, the input of the previous step is transformed into an initial fusion summary with high security strength, thereby providing an unpredictable input basis for subsequent entropy enhancement confusion and dynamic salt value generation.

[0065] For example, in the cold chain logistics system of a pharmaceutical manufacturing company, the batch feature vector includes the national drug approval number "H20180001", the production date timestamp 1672531200, and the expiration date timestamp 1735689600, which are serialized and encoded into a 32-byte BatchVec. The calibration time reference parameter, obtained as a drift-filtered double-precision value of 1630483200.123456 at UTC time "2024-09-01T10:00:00.123456", is encoded into an 8-byte TimeCal. The BeiDou time synchronization deviation compensation value is measured to be -0.000245 seconds, encoded into an 8-byte BBDSync. The three data segments are concatenated in a predetermined order to form a 48-byte fused sequence, and a single-round 512-bit message compression operation is performed using the national cryptographic SM3 algorithm to obtain a digest value of 0x7ac9...f032 (the middle part is omitted). This summary value is used as the initial fusion summary data block output. In actual deployment, this summary value is applied to subsequent entropy source enhancement. By introducing environmental noise seed code to construct dynamic salt values, performance tests show that the generated summary data block, combined with the above splicing and single-round SM3 hashing, exhibits significantly improved unpredictability and anti-replay characteristics in the entropy distribution of different batches of drugs.

[0066] S3.5: Perform secondary entropy enhancement obfuscation processing on the initial fusion digest data block, and XOR the environmental noise seed code released by the National Time Service Center on the same day to finally output a spatiotemporal entropy source with cryptographic security strength and irreversible derivation, which serves as the dynamic salt value input variable for the subsequent key derivation protocol.

[0067] The initial fusion digest data block generated in the preceding steps is loaded as a read-only input object in a trusted computing environment. An environmental noise seed code released by the National Time Service Center on the same day is selected as an external random perturbation source and imported into an isolated computing buffer. Its bit length is confirmed to be consistent with the digest data block to ensure the correspondence of subsequent bitwise operations. The bit processing engine is invoked to perform a bitwise XOR operation on the initial fusion digest data block and the environmental noise seed code, generating an intermediate obfuscated data stream containing dual-source randomness. This XOR operation relies on the bit matching of both inputs to reduce the predictability of a single data source. The intermediate obfuscated data stream undergoes secondary hash perturbation processing. The national cryptographic SM3 algorithm is used to introduce nonlinear compression and multiple rounds of bit permutation on top of the inherent digest, forming a perturbed digest value with global diffusion characteristics. The perturbed digest value is then byte-level replaced with a set of preset irreversible mapping tables to further weaken the correlation between the original digest and the noise seed code, ensuring that the original data from any input source cannot be derived through reverse computation. The replaced encoded data stream undergoes a solidification verification process to confirm that the bit length, symbol distribution, and hash collision detection results meet the security standards for key-derived salt values. This salt is then marked as the final spatiotemporal entropy source and output to the subsequent key derivation protocol module. By introducing an external physical random source and bit-level obfuscation, the fusion digest from the previous step is transformed into a dynamic salt value with cryptographic security strength and irreversible derivability. This enhances the randomness of the drug digital identity generation process and improves the security of the source data in a heterogeneous node environment.

[0068] For example, in the outbound process of a batch of biological products, the initial fused summary data block is 256 bits long, generated by SM3 hash compression based on the national drug approval number, production date stamp, expiration date, UTC microsecond-level calibration time, and BeiDou time service deviation compensation value. The environmental noise seed code released by the National Time Service Center is also 256 bits long, calculated by mixing geomagnetic disturbances, long-wave noise, and time service signal perturbations. The two are XORed bitwise in the TEE buffer. For example, if the initial summary value at bit 34 and the noise code at bit 34 are 1 and 0 respectively, the XOR result is 1. After performing a full 256-bit XOR, an obfuscated data stream is obtained. The SM3 hash algorithm is applied to the obfuscated data stream to form a perturbed summary value, and replacement encoding is performed according to a preset irreversible mapping table (such as replacing byte 0xAF with 0x3C). The final output spatiotemporal entropy source is solidified with a check bit length of 256 bits and passes the collision test. It is used as the input variable for the dynamic salt value of the key derivation and applied to the subsequent distributed key derivation process. The measured time for generating digital identity of drugs is significantly reduced and the identity identifier cannot be obtained by reverse engineering from a known digest, thus achieving a dual enhancement of randomness and security.

[0069] like Figure 3As shown, step S4: Utilizing a trusted execution environment, a distributed key derivation protocol is initiated. Using the node capability fingerprint as the root key and the spatiotemporal entropy source as the salt, multiple rounds of lightweight hash iterations are performed to generate a drug-specific private key and simultaneously derive a decentralized digital identity identifier conforming to a four-segment encoding structure. Specifically, this includes: S4.1: Initialize and configure the secure storage area within the trusted execution environment. Perform memory isolation mapping processing based on the byte sequence of node capability fingerprints and the random bit stream of spatiotemporal entropy sources to obtain the root key seed and dynamic salt value parameters. Specifically, construct a secure operational context environment containing the root key seed and dynamic salt value parameters to obtain a key derivation basic data block with hardware-level protection against side-channel attacks.

[0070] The Trusted Execution Environment (TEX) is a secure computing region created and forcibly isolated by hardware such as a CPU, and independent of the main operating system.

[0071] Based on the byte sequence of the node capability fingerprint output from the preceding steps and the random bit stream of the spatiotemporal entropy source, the secure storage area configuration interface inside the Trusted Execution Environment (TEE) is loaded, and the access control list in the runtime domain is set to limit the read and write permissions of the storage area to only the key-derived process.

[0072] The Memory Management Unit (MMU) is invoked to perform an isolation mapping operation, mapping the byte sequence of the node capability fingerprint to the root key register of the secure storage area, and mapping the random bit stream of the spatiotemporal entropy source to the dynamic salt register, ensuring that the two registers are physically isolated and that their logical access paths do not interfere with each other.

[0073] The hardware random access protection mechanism is triggered inside the TEE to perform cryptographic locking on the cache line of the mapped register, preventing side-channel attacks from speculating on the root key seed or salt value parameters through the cache.

[0074] The secure arithmetic logic unit (ALU) is invoked to perform a checksum calculation on the initial bit sequence of the root key register and the dynamic salt register, and the data integrity is verified using the following formula: Among them, b i For the i-th byte of the input bit block, the mod operation ensures that the checksum is within a single byte range. C sum To verify and calculate the results.

[0075] The verified data is merged into a key derivation basic data block, a unique session identifier is registered in the TEE secure computing unit, and the binding status of the root key seed and dynamic salt value parameter is recorded, providing hardware-level protection against side-channel attacks for subsequent hash iteration derivation links.

[0076] By configuring and isolating the TEE secure storage area, the node capability fingerprint and spatiotemporal entropy source from the previous step are transformed into a key derivation basic data block with access control, physical isolation and data integrity verification, thereby achieving security and consistency in the process of drug digital identity derivation in a heterogeneous node environment.

[0077] For example, in a pharmaceutical cold chain vehicle-mounted TEE, the secure storage area is set to 4096 bytes, the serialized node capability fingerprint occupies 256 bytes, and the random bit stream from the spatiotemporal entropy source occupies 512 bytes. The access control table is configured to map the root key register to physical address 0x1000 and the dynamic salt register to 0x1200, enabling cache line encryption locking mode. During checksum calculation, each bit block is grouped into 64-byte blocks, summed using a formula, and moduloed to obtain a checksum within a 256-bit range. After verifying the data is correct, these blocks are merged into a 768-byte key derivation base data block. In performance verification, the side-channel detection module did not capture any cache access anomalies, ensuring that the secure derivation effect of the root key and salt encapsulated in the TEE is significantly improved, and the subsequent hash iteration latency remains within the expected range.

[0078] S4.2: Based on the key-derived basic data block, a lightweight hash iteration algorithm is called to perform multiple rounds of hybrid compression transformation processing. The root key seed is used as the initial input vector and XORed with the dynamic salt value parameter to generate an intermediate derived key stream with unidirectional irreversible characteristics, thereby obtaining a high-entropy private factor sequence for subsequent asymmetric encryption operations.

[0079] Based on the key derivation base data block already built in the trusted execution environment, the pre-built lightweight hash iteration algorithm module is called to initialize and load the root key seed byte sequence and establish a mapping dependency relationship with the dynamic salt value parameter, ensuring that the input data remains consistent and immutable in isolated memory.

[0080] The first round of XOR fusion operation is performed on the loaded root key seed, and it is then processed bitwise with the dynamic salt value bit stream. High entropy randomness is introduced through bit-level perturbation and any possible input pattern correlation is eliminated to obtain the first round of intermediate variable matrix.

[0081] Based on the results of the first round of fusion, multiple rounds of hybrid compression transformation are performed. Each iteration includes hash compression of the national cryptographic SM3 algorithm and bit rotation of the international SHA-256 algorithm to ensure the elimination of local deviations under cross-algorithm combination. The number of iterations can be dynamically adjusted in a trusted execution environment according to hardware performance.

[0082] The intermediate derived key stream is calculated using the iteration round control factor and the digest bit stream output from the previous round, according to the following formula: Among them, K i For the i-th round of derived key stream, K i-1 For the previous round's key stream, S i Let be the salt value segment of the i-th round, and ⊕ represents the bitwise XOR operation.

[0083] After the iteration is completed, the uniformity and non-repetition of the final key stream bit distribution are checked by the entropy detection module. If it meets the high entropy characteristic standard, it is converted into a high entropy private factor sequence and encapsulated into a dedicated register area of ​​the trusted execution environment.

[0084] By using the above hybrid compression iterative processing method, the basic data block of the previous step is transformed into a high-entropy private factor sequence with unidirectional irreversible properties and suitable for subsequent elliptic curve asymmetric encryption operations, thereby achieving the core key security enhancement effect in the process of generating drug digital identity.

[0085] For example, in a scenario where the capability fingerprint seed length for a pharmaceutical logistics node is 256 bits and the dynamic salt value parameter length is 128 bits, after the trusted execution environment loads the root key seed and salt value, the bit flip rate of the first round of XOR operation is controlled at 0.49, and the number of iteration rounds is set to 8 rounds, each round including a mixture of SM3 hash compression and SHA-256 bit rotation. According to the formula: When i=1, the input is the XOR result of the original seed and the salt value of the first piece, and the output is a 256-bit intermediate digest; when i=8, the output 256-bit final digest is evaluated by the entropy detection module, and its bit distribution uniformity reaches the preset high entropy threshold. The generated private factor sequence is used for subsequent elliptic curve scalar operations. In the verification, its public key generation rate and private key security are significantly improved, meeting the requirements of global uniqueness and collision resistance of drug digital identity in a heterogeneous node environment.

[0086] S4.3: Perform elliptic curve scalar multiplication on the high-entropy private factor sequence, select a pre-set pharmaceutical consortium blockchain dedicated generator point as the reference coordinate, calculate the corresponding public key coordinate point pair and solidify the private key value, and obtain a drug-specific key that conforms to the national cryptographic standard. The private key value is only stored inside the trusted execution environment and is never exported.

[0087] The pre-defined dedicated generator point for the pharmaceutical consortium blockchain refers to a standard elliptic curve base point pre-defined and embedded in the node code by the on-chain consensus protocol within the blockchain's cryptographic system. It serves as the unique reference coordinate jointly recognized by all consortium blockchain members and used for asymmetric key generation. During key derivation, the system performs scalar multiplication at this fixed point to ensure that all drug-specific public keys generated by all nodes are based on the same mathematical curve and starting point, thereby guaranteeing the mutual recognition, verifiability, and cryptographic consistency of keys throughout the entire consortium blockchain.

[0088] Using the high-entropy private factor sequence generated in the preceding step S4.2 as input for elliptic curve cryptography, the SM2 algorithm support unit built into the trusted execution environment is invoked to load the dedicated generator point coordinate parameters for the pharmaceutical consortium blockchain. The private factor sequence is mapped to curve domain parameters and the scalar multiplication context is initialized via a secure key scheduler. Elliptic curve scalar multiplication is performed on the private factor sequence. The secure multiplication core is used to calculate the product coordinate pairs of the generator point and the scalar within the finite field Fp, forming a set of valid public key coordinates conforming to the preset curve equation y²=x³+ax+b, where a and b are coefficients defined on the finite field Fp.

[0089] During the scalar multiplication process, a cyclic redundancy check (CRC) module is invoked to verify intermediate multiplication results, ensuring that each iteration of multiplication conforms to the modulo operation rules of curve order n. The calculated public key coordinates are written into a temporary buffer of the trusted execution environment, and the corresponding private key value is solidified in a secure storage unit under hardware entropy source triggering conditions, forming a complete drug-specific key. One-way hash verification performed during key solidification ensures that the private key value cannot be extracted reversibly, and that the private key exists only within the trusted execution environment and is marked as prohibited from being exported. Through the above elliptic curve scalar multiplication and private key solidification process, the high-entropy private factor sequence from the previous step is transformed into public key coordinate data that can be used for subsequent identity encoding and signature verification, realizing the generation and secure solidification of the drug-specific key.

[0090] For example, in a pharmaceutical consortium blockchain application scenario, the trusted execution environment loads the pre-set curve generator point coordinates (Gx, Gy) as (28532012730123, 95187462308411), and the curve order is set to n=115792089237316195423570. At this time, the high-entropy private factor sequence is securely mapped to form a scalar value k=627710173538668076383578. Scalar multiplication within the finite field Fp is then performed. Where Q is the public key coordinate pair and G is the generator point coordinate, Q = (83492034820394, 19485723094875) is obtained through multiple rounds of double addition. The private key value k is then embedded in the trusted execution environment security unit, and a one-way hash verification is performed. To verify the integrity of the private key, a drug-specific key (Q, k) is ultimately output. During node authentication, this public key coordinate can directly participate in blockchain transaction signing and source verification. The key generation process strictly follows national cryptographic standards, ensuring the uniqueness of the identity and the credibility of transaction verification.

[0091] S4.4: Extract feature hash fragments based on the public key coordinate point pairs in the drug-specific key, and perform structured splicing and assembly processing by combining the standard encoding string of the drug batch number, the truncated check code of the node capability fingerprint, and the cyclic redundancy check value of the timestamp to construct a four-segment identity encoding string containing source traceability features, thereby obtaining a globally unique decentralized digital identity identifier.

[0092] Based on the public key coordinate point pair in the drug-specific key, the public key feature extraction module is called to perform SM3 hash mapping on the horizontal and vertical coordinates, and the result is truncated to a fixed length to form feature hash fragment data.

[0093] The standard encoding string of drug batch number stored in the trusted execution environment is loaded into the structured splicing cache area and written into the batch number field according to the predefined position encoding mapping table to ensure that the batch number segment has a standardized format and consistent length.

[0094] Extract the MD5 truncated checksum from the node capability fingerprint data, call the truncated checksum parsing module to convert it into an indexable hexadecimal string, and write it into the corresponding performance feature segment in the concatenation buffer.

[0095] The access timestamp processing unit performs a CRC16 cyclic redundancy check operation on the current UTC microsecond-level timestamp, and fills the resulting two-byte result into the end position of the splicing buffer to form a time-related verification segment.

[0096] The structured splicing and assembly module is invoked to integrate the aforementioned four types of data segments in the order of "PDID-medical field-specific prefix + batch number segment + fingerprint truncation segment + timestamp verification segment". This ensures that each segment uses a fixed delimiter and meets the global uniqueness verification rules, and outputs a four-segment identity code string.

[0097] Through the above structured splicing process, the public key characteristics, batch number, performance characteristics, and time verification information from the previous step are transformed into unified coded data containing source traceability characteristics, thereby achieving the expected technical effect of global uniqueness of decentralized digital identity identifiers and reverse verification of source node capabilities.

[0098] For example, during the outbound process of a batch of biological products, the public key's horizontal axis hash value is set to a 16-byte hexadecimal string "8FA3B2E019AC45D7", and the vertical axis hash value is "4B7C92A1D3E8F905". After merging, a truncation operation is performed to obtain an 8-byte feature hash fragment "8FA3B2E0D3E8F905". The standard encoding string for the drug batch number is "BX20240618A001", the node capability fingerprint MD5 truncation checksum is "9C4D2A6B", the current UTC microsecond-level timestamp is "202406181230451234", and the CRC16 check result is calculated by the algorithm module to obtain the hexadecimal string "3F52". The CRC16 calculation formula is as follows: Where Init is the initial register value and data is the byte sequence of the input timestamp. In this embodiment, Init is 0xFFFF, which is processed by iterative XOR and polynomial division by bytes to obtain the result 0x3F52. The assembly module concatenates the data according to the rule "PDID-MED+BX20240618A001+9C4D2A6B+3F52" to generate the final identity code "PDID-MED-BX20240618A001-9C4D2A6B-3F52". In the consortium blockchain registration transaction verification, this identity code is parsed back to the batch number, node performance characteristics and timestamp verification segment, which can significantly improve the accuracy of source verification in the traceability process and maintain low computational overhead and high consistency in node capability fingerprint verification.

[0099] S4.5: Bind and encapsulate the decentralized digital identity identifier and the drug-specific key, and use the signature engine of the trusted execution environment to generate an identity registration certificate data packet to complete the final generation and local security solidification of the drug digital identity at the logical level, and obtain a complete identity authentication object that can be directly written into the blockchain registration transaction.

[0100] The process involves binding and encapsulating decentralized digital identity identifiers with drug-specific keys. Using an identity binding buffer within a trusted execution environment (TEE) as the input container, the identity identifier string and public key coordinate pairs undergo byte-level serialization mapping to generate uniformly aligned identity binding sequence data. Based on this sequence data, the TEE's key protection module is invoked to perform a one-time reference to the private key value, constructing a composite binding structure containing a public key verification factor and the identity identifier. After the composite binding structure is generated, the TEE's signature engine loads the private key value, performs elliptic curve digital signature operations on the identity binding sequence data, and packages the signature result and binding sequence data together into a raw identity registration credential data packet. A hash digest is generated from the raw identity registration credential data packet to produce a SHA3-256 signature verification code, which is written into the verification field of the raw data packet to obtain an identity registration credential data packet with tamper-proof verification capabilities. After assembling the identity registration credential data packet, it is permanently stored in a secure storage partition within the TEE and marked as exportable for direct use in initiating blockchain registration transactions, achieving the final logical generation and local secure solidification of the drug's digital identity.

[0101] By sequentially performing serialization mapping, key protection reference, signature operation, hash verification, and permanent solidification, the decentralized digital identity identifier and drug-specific key generated in the previous step are transformed into identity registration credential data with a complete signature authentication chain and tamper-proof verification capabilities, thus realizing a complete identity authentication object that can be directly accepted by the blockchain network.

[0102] For example, in the cold chain drug delivery process of the pharmaceutical consortium blockchain, the decentralized digital identity identifier loaded in the trusted execution environment is 64 bytes long. The public key coordinate points use the national cryptographic standard SM2 curve, with the x-axis and y-axis each being 256 bits. After serialization and mapping, a binding sequence data with a total length of 584 bytes is formed. The private key value is 256 bits, and the binding sequence data is signed using the SM2 signature algorithm, outputting a signature result of 64 bytes. In the signing step, the hash function is set to SHA3-256, and the generated hash checksum is 32 bytes, which is written to the credential verification field. The trusted execution environment combines the 584-byte binding sequence data, the 64-byte signature result, and the 32-byte checksum into an identity registration credential data packet with a total length of 680 bytes, and then stores it in a permanent secure storage partition. When a blockchain registration transaction is initiated, the data packet is read directly. The signature verification passes and the hash verification value matches, successfully registering the drug identity on the chain. This achieves the anchoring of identity with node capability fingerprints. The verification results show that the identity registration certificate performs stably in the cold chain delivery node, with the signature verification time remaining within 2 milliseconds and the solidified storage read latency not exceeding 1 millisecond. This significantly improves the security and continuous availability of drug identity binding in the heterogeneous node environment of the consortium blockchain.

[0103] Step S5: Perform a SHA3-256 hash operation on the node capability fingerprint to generate an anchor hash value, and write this anchor hash value as a metadata field into the on-chain registration transaction containing the decentralized digital identity identifier, thus completing the implicit anchoring of node capabilities and drug identity. Specifically, this includes: S5.1: Perform binary serialization encoding on the node capability fingerprint generated in the previous steps, converting the original hardware resource data, which includes the encryption algorithm support type, millisecond jitter range level, and three-level encoding storage throughput capability, into a standard byte stream format to obtain a standardized fingerprint data block with a fixed length that meets the input requirements of the hash algorithm.

[0104] S5.2: Based on the standardized fingerprint data block, call the national cryptographic or internationally accepted SHA3-256 hash algorithm to perform a one-way hash transformation operation, and eliminate local data correlation through multiple rounds of bit permutation and modulo addition operations to generate an anchor hash value with anti-collision characteristics and fixed length.

[0105] The standardized fingerprint data block obtained through serialization in step S5.1 is processed by calling the pre-built SHA3-256 hash algorithm core engine to perform a one-way hash transformation operation to construct an anchor hash value with collision resistance. The standardized fingerprint data block is then imported into the bit-filling module of the hash algorithm, generating an extended data stream that meets the 512-bit block length requirement through a filling rule based on message length. The initial vector register of the hash algorithm is loaded with eight 64-bit initial constant parameters specified by national cryptographic standards or international standards to ensure standard consistency in digest calculation. Multiple rounds of state permutation operations are performed on the filled data blocks. Each round includes byte stepping, column mixing, and XOR modulo addition operations based on Keccak permutation. These multiple rounds of bit permutation and modulo addition eliminate local correlations in the input data and enhance confusion strength. The contents of the intermediate state register from each round are XORed and superimposed with the current block data to achieve iterative, cumulative, non-linear state transitions, ensuring a globally uniform distribution of the output digest value. The hash algorithm's compression function module performs a final permutation and extraction on the state register after iteration, outputting a fixed-length 256-bit digest value. This digest value is then solidified as the anchor hash value for subsequent on-chain registration. Through this chain-like processing, the standardized fingerprint data block from the previous step is transformed into irreversible, collision-resistant node-capable fingerprint digest data, achieving the fundamental cryptographic properties required for implicit anchoring.

[0106] For example, in a pharmaceutical cold chain logistics scenario, for a certain cold chain transport vehicle gateway node, the standardized fingerprint data block obtained through step S5.1 is 1024 bits long. After padding with SHA3-256 padding rules, it is increased to 1536 bits, i.e., three 512-bit blocks. The hash engine register is loaded using the initial constant parameters specified in the national cryptographic standard, and 24 rounds of Keccak permutation operations are performed on each block. After performing an XOR operation on the status register and the block data, a global status hash stream is obtained. Finally, the first 256 bits of the status register are extracted as the output digest value using a compression function, conforming to the following formula: Where State is the current algorithm status register content, Block is the padded data block, ⊕ is the bitwise XOR operation, and Permute is the current state register content. 24 Extract for 24-wheel Keccak replacement 256b The first 256 bits are extracted. The result is a fixed-length anchor hash value, which can be directly used as a metadata field during on-chain registration to achieve secure implicit anchoring of drug identity and node capability characteristics. In different node environments, the distribution characteristics of this digest value have been verified to have significantly improved uniformity and collision resistance, ensuring the consistency and security of the traceability system under various heterogeneous hardware conditions.

[0107] S5.3: Using the metadata encapsulation protocol predefined by the smart contract, the anchor hash value is mapped to the payload field of the on-chain transaction, and associated with the decentralized digital identity identifier of the current drug to construct a transaction object to be signed containing identity binding relationship, so as to form an on-chain registration request data packet with complete context information.

[0108] The predefined metadata encapsulation protocol of the smart contract is a standardized set of data packaging and structuring rules within the pharmaceutical consortium blockchain. It explicitly specifies how to assemble the off-chain generated anchor hash value, the decentralized digital identity identifier of the drug, and other necessary contextual information (such as timestamps and operation types) into a structured, machine-readable transaction payload according to a specific field order and encoding format. The core purpose of this protocol is to enable smart contracts to accurately identify and verify the binding relationship between hardware fingerprints and drug identities, thereby driving the automatic and reliable execution of on-chain business processes such as node registration and identity anchoring.

[0109] S5.4: Based on the consensus node of the consortium blockchain, perform digital signature verification and format compliance check on the on-chain registration request data packet. After confirming the transaction initiator's authority and the integrity of the data structure, permanently write the metadata field containing the anchor hash value into the block body of the distributed ledger to generate an immutable on-chain registration transaction record.

[0110] The consensus nodes in the consortium blockchain refer to the core member servers authorized to participate in block production and verification within the permissioned blockchain network of the pharmaceutical consortium blockchain. They run the same consensus algorithms, such as PBFT and Raft, and are jointly responsible for verifying the legality and sorting of transactions such as on-chain registration request data packets, and reaching a consensus state. Their core function is to ensure that all data written to the distributed ledger, such as drug identity binding records, is authorized, formatted correctly, and immutable, thereby maintaining the data consistency and trustworthiness of the entire network.

[0111] Based on the on-chain registration request data packet generated by the preceding steps, the receiving interface of the consortium blockchain consensus node is invoked to load the data packet into the transaction queue to be verified. The transaction type is identified as identity anchor registration to trigger the subsequent node permission verification process. The digital signature field in the received on-chain registration request data packet is decoded, and the signature authenticity is verified by using the pre-built root public key certificate and node public key mapping table of the consortium blockchain, generating a signature verification result flag. According to the generated signature verification result flag, the initiator node identifier in the transaction request is matched against the consortium blockchain access node whitelist. If a match is found, the attachment data structure definition and metadata field encoding format are extracted, and the transaction data packet is checked for format compliance to determine its conformity in byte length, field order, and encoding specifications. The transaction request that passes the format compliance check is written into the process by the consensus node. The metadata field containing the anchor hash value is aligned according to the transaction payload encoding specification, and the field is embedded into the block body payload of the current block production task through the block construction module. For blocks containing anchor hash values, perform multi-replica synchronous broadcasting. After confirming the block submission status using the consortium blockchain consensus algorithm, permanently store the block in the historical record area of ​​the distributed ledger to generate an immutable on-chain registration transaction record.

[0112] By using digital signature verification and format compliance checks, the on-chain registration request data packet from the previous step is transformed into an immutable registration transaction record in the blockchain ledger, thereby implicitly anchoring node capabilities and drug digital identity in a distributed environment.

[0113] For example, in a cold chain transportation scenario for biological products, the digital signature field of the on-chain registration request data packet is 256 bits long, using the national cryptographic standard SM2 for asymmetric signature verification. The public certificate store contains the public keys of 128 admitted nodes. During the verification process, the initiating node identifier is found to match whitelist sequence number 36. The format compliance check sets the metadata field to a fixed byte length of 64 bytes, with the field order being identity identifier, node capability digest value, and timestamp. The encoding uses UTF-8 and performs redundancy verification using CRC16. When the consensus node executes the write process, it embeds the anchor hash value into the block body's payload in 64-byte alignment and confirms the transaction submission using the PBFT algorithm in this round of consensus. The block height increases to 10234, and the transaction hash index value is permanently fixed in all ledger copies after generation. The output in this scenario is that the on-chain registration transaction record contains a complete identity anchoring relationship. After verification, it can significantly improve the anchor matching success rate in subsequent drift verification operations and provide a stable trust benchmark for rapid tracing of temperature control anomalies in cold chain transportation.

[0114] S5.5: Based on the block height and transaction hash index of the on-chain registered transaction records, establish a two-way mapping index table between the anchor hash value and the decentralized digital identity identifier of the drug, so as to complete the implicit logical anchoring of the heterogeneous performance characteristics of the node and the identity of the drug throughout its entire life cycle, and provide a traceable initial root of trust for subsequent fingerprint drift verification.

[0115] The input condition is the on-chain registration transaction record generated in step S5.4. This record contains a block height data field and a transaction hash index field, and also has the association information of the anchor hash value and the decentralized digital identity identifier of the drug. The block height field of this on-chain registration transaction record is extracted and stored in the local index building cache module as the first index dimension data. The transaction hash index field is subjected to one-way mapping encoding and stored in the cache module as the second index dimension data, maintaining the mapping relationship with the first index dimension. The anchor hash value parsing interface is called to extract the digest value stored in the block body and perform standardized verification processing to ensure that the data length and hash algorithm version are consistent, so as to establish a precise match between the anchor hash value and the blockchain index later. The decentralized digital identity identifier is segmented and parsed, extracting the batch number hash fragment, truncated check code, and timestamp CRC segment to generate an identity resolution result that can uniquely verify the performance characteristics of the source node, and stored in the index cache as the third index dimension. A dual-key index table structure is established based on the first and second index dimensions, using the anchor hash value as the foreign key and the decentralized digital identity identifier as the reverse foreign key to achieve structured storage of bidirectional mapping relationships. Through the above bidirectional mapping index construction method, the on-chain transaction records of the previous step are transformed into traceable index data that can be called for subsequent fingerprint drift verification, realizing the implicit logical anchoring of the heterogeneous performance characteristics of nodes and the identity of the entire life cycle of drugs, and providing an initial root of trust based on the blockchain.

[0116] For example, in a drug batch release registration transaction, the block height is 125000, the transaction hash index is "0xA37BC…F19E", the anchor hash value, after SHA3-256 processing, is "0x9F73…D661", and the decentralized digital identity identifier is "PDID-AB12-CD34-EF56". The block height is extracted and used as the first index dimension, the transaction hash index is Base58 encoded and stored as the second index dimension, the anchor hash value is standardized and verified to be 256 bits in length and hashed using SHA3-256, and the decentralized digital identity identifier is parsed into the batch number hash fragment "AB12", the truncated checksum "CD34", and the timestamp CRC segment "EF56" and stored as the third index dimension. A mapping table is constructed using a dual primary key structure, where the block height and the transaction hash index both point to the anchor hash value, and the anchor hash value in turn points to the decentralized digital identity identifier. The index table has been verified through on-chain query operations. During the fingerprint drift verification stage, it can quickly match the original node capability data and confirm the continuity of identity binding. In the cold chain transportation scenario, it significantly improves the drift detection response speed and maintains a retrieval latency of less than 5ms during peak periods.

[0117] Step S6: When a node device change is detected, resulting in a new node capability fingerprint, calculate the Hamming distance between the new node capability fingerprint and the node capability fingerprint corresponding to the original anchor hash value, and generate an edit distance value characterizing the degree of fingerprint drift. Specifically, this includes: S6.1: Perform bit-by-bit alignment processing on the new node capability fingerprint triggered by the node device change event and the original node capability fingerprint corresponding to the original anchor hash value to obtain an equal-length binary bit sequence pair containing the encrypted instruction set encoding, memory jitter level encoding and storage throughput level encoding.

[0118] S6.2: Perform a bitwise XOR operation on the equal-length binary bit sequence pair to generate a difference mask vector representing the difference distribution of the capability fingerprints of the two nodes in the hardware resource feature dimension.

[0119] For the equal-length binary bit sequence pairs obtained by bit-by-bit alignment in step S6.1, the bit operation processing module is first called to perform bitwise logical XOR on the three types of fields: hardware instruction set encoding, memory jitter level encoding, and storage throughput level encoding, to ensure that a difference identifier is generated for each corresponding bit.

[0120] For each bit generated during the XOR operation, according to the logical rules, the same state bit is output as 0 and the different state bit is output as 1, so as to accurately record the difference distribution of the capability fingerprints of the new and old nodes in each hardware resource feature dimension in the difference mask.

[0121] The generated difference mask vector is mapped in multiple segments according to the field order to maintain its consistent structure in the three dimensions of hardware instruction set, memory response, and storage performance, so as to locate the differences by dimension in subsequent statistics and drift coefficient calculation.

[0122] The difference mask vector is stored in a fixed-length buffer to avoid threshold judgment errors caused by inconsistent data segment lengths, and to provide reliable input for the cumulative statistics in the subsequent S6.3 sub-step.

[0123] Through the bitwise XOR process described above, the bit-aligned binary bit sequence is transformed into a difference mask vector representing the differences in hardware characteristics, thereby realizing a structured expression of the differences in node capability fingerprints.

[0124] For example, in a heterogeneous node environment, the hardware instruction set encoding of the new node capability fingerprint is 10101100, and the hardware instruction set encoding of the original node capability fingerprint is 11100100; the memory jitter level encodings are 01101 and 01011, respectively; and the storage throughput level encodings are 10 and 11, respectively. These three types of encodings are concatenated in order to obtain equal-length binary bit pairs. Through XOR operations, a difference mask of 01001000 is generated for the hardware instruction set encoding; a difference mask of 00110 is generated for the memory jitter level encoding; and a difference mask of 01 is generated for the storage throughput level encoding. These three difference masks are concatenated in field order to form the final difference mask vector 010010000011001, which is stored in a 16-bit buffer. If the Hamming distance formula is used, the accumulated result in this example is 8, indicating that there are 8 differences in the positions of the new and old node capability fingerprints. This data will be used as input for subsequent drift coefficient calculations.

[0125] S6.3: Perform cumulative statistical processing on the bits with a value of 1 in the difference mask vector to calculate the total number of bit flips in the three dimensions of hardware instruction set, memory response latency and storage throughput of the new node capability fingerprint relative to the original node capability fingerprint.

[0126] S6.4: Using the total number of bit flips as the numerator and the total bit length of the node capability fingerprint as the denominator, perform a normalization ratio calculation to generate a relative drift coefficient characterizing the magnitude of changes in the node's hardware environment.

[0127] S6.5: Based on the mapping relationship between the relative drift coefficient and the preset fingerprint tolerance threshold, perform discretization mapping processing to output the final edit distance value that characterizes the degree of fingerprint drift and is used for identity binding continuity determination.

[0128] After obtaining the mapping table between the relative drift coefficient and the preset fingerprint tolerance threshold as input conditions, the relative drift coefficient is subjected to interval positioning operation, and it is matched one by one with the discrete threshold segments defined in the mapping table to determine the corresponding discrete drift level number.

[0129] After determining the drift level number, the level-to-edit distance value conversion function in the mapping relationship is called to perform a one-way mapping on the drift level number and output the integer edit distance candidate value corresponding to the level number.

[0130] The integer edit distance candidate values ​​are weighted and fused with the input relative drift coefficients. The weighting factors are derived from the confidence parameters for each drift level in the mapping table to generate the corrected real edit distance values.

[0131] The corrected edit distance real value is standardized and mapped to the edit distance standard domain range specified by the consortium blockchain consensus protocol to ensure that the drift degree between different node capability fingerprints is uniform.

[0132] The corrected edit distance value is calculated using the following formula: Where D is the final output edit distance value, f is the mapping table transformation function, P is the relative drift coefficient, and w is the confidence weight of the corresponding drift level.

[0133] Through the above discretization mapping and weighted correction processing, the relative drift coefficient obtained in the previous step is transformed into an edit distance value used for identity binding continuity determination, thereby realizing the quantitative expression of the node capability fingerprint drift amplitude by the system.

[0134] For example, in a cold chain transportation scenario for a biological product, the total bit length of the node capability fingerprint is 64, and the number of bit flips detected is 5. Then the formula for calculating the relative drift coefficient is 5 / 64, and the result is 0.078125.

[0135] In the preset mapping table, the interval from 0 to 0.1 corresponds to the drift level number 1, the candidate edit distance value output by the mapping function f is 4, and the drift level 1 corresponds to the weight factor 0.5.

[0136] By fusing the candidate edit distance values ​​with the relative drift coefficient, the edit distance value calculation formula is corrected as follows: The calculated result is 4.0390625.

[0137] The corrected value is standardized and mapped to the standard domain [0,10] specified in the consensus protocol. The normalized value remains within a low drift range, and the system determines that the identity binding relationship can be continuously migrated, eliminating the need for re-authentication. This embodiment significantly improves the accuracy of identity anchor continuity determination in consortium blockchains under dynamic changes in heterogeneous nodes, effectively avoiding unnecessary re-authentication operations caused by inaccurate drift value determination.

[0138] Step S7: Determine whether the edit distance value is less than or equal to a preset tolerance threshold. If the condition is met, directly update the anchor hash value stored in the on-chain registration transaction to achieve seamless migration of the identity binding relationship. If the condition is not met, trigger the minimized re-authentication process. Specifically, this includes: S7.1: Obtain the original node capability fingerprint corresponding to the new node capability fingerprint generated by the previous steps and the original anchor hash value. Take the new node capability fingerprint and the original node capability fingerprint as input objects and perform bitwise XOR logic operation to generate an initial binary difference sequence representing the difference state of two data bits.

[0139] In step S7.1, the original node capability fingerprint corresponding to the new node capability fingerprint generated by the previous step S6 and the original anchor hash value is obtained as input objects. The two are subjected to morphological regularization processing before precise bit-level matching. The character data involving encryption instruction set encoding, memory jitter level encoding and storage throughput level encoding are converted into equal-length binary sequences and byte alignment is guaranteed.

[0140] The two equal-length binary sequences are loaded into the bit operation unit of the on-chain verification module, and bitwise XOR logic operation is performed on the corresponding bits to remove identical characteristic bits and mark the difference bits as a value of 1.

[0141] The result of the XOR logical operation is mapped to an initial difference binary sequence, where a difference bit value of 1 indicates that the feature dimension has changed, and a difference bit value of 0 indicates that the feature dimension remains unchanged.

[0142] We employ a hardware register-based shift-accumulation operation to optimize the storage of the initial difference binary sequence, ensuring that subsequent statistical processing can quickly locate the difference bits within a single period.

[0143] By using the bitwise XOR processing method described above, the difference between the original value and the new value of the node capability fingerprint is explicitly expressed as an initial binary difference sequence, realizing the visualization and isolation of the difference features, and providing an efficient input object for subsequent accurate calculation of Hamming distance and tolerance threshold comparison.

[0144] For example, in an on-chain identity migration verification, the new node capability fingerprint is encoded as 010110011001, and the original node capability fingerprint is encoded as 011010011000. After converting both into equal-length binary sequences, an initial difference binary sequence is generated using bitwise XOR logic. In the first bit, both are the same, and the XOR result is 0; in the second bit, the new code is 1 and the old code is 1, resulting in 0; in the third bit, the new code is 0 and the old code is 1, resulting in 1; this process continues until all bits are XORed, resulting in the difference sequence 001100000001. The calculation of the XOR result can be expressed as: Where D is the initial difference binary sequence, N is the new node capability fingerprint bit sequence, and O is the original node capability fingerprint bit sequence. This difference sequence is used in S7.2 for the accumulation and statistics of difference bits, ultimately quantizing the drift amplitude. In this embodiment, the difference bits only appear in the 3rd, 4th, and 12th bits, with a total of 3 difference bits, which significantly improves the drift determination accuracy and ensures the traceability of bit differences in the hardware resource feature dimension.

[0145] S7.2: Based on the initial binary difference sequence, the discrete bits with a value of 1 in the sequence are counted by bit statistical accumulation algorithm to quantify and calculate the accurate Hamming distance value that characterizes the degree of fingerprint drift.

[0146] S7.3: Obtain the fingerprint tolerance threshold parameter preset in the consortium blockchain consensus strategy, and perform a size comparison logic judgment process between the precise Hamming distance value and the fingerprint tolerance threshold parameter to generate a Boolean verification result flag bit representing the compliance of identity migration.

[0147] The precise Hamming distance value obtained from the preceding step S7.2 is subjected to threshold acquisition processing before parameterization comparison. The storage unit of the fingerprint tolerance threshold is located in the consensus strategy configuration storage of the consortium blockchain and the corresponding value is read to obtain the standard tolerance parameter used for identity migration compliance determination.

[0148] The precise Hamming distance value and the standard tolerance parameter are uniformly converted into a fixed-length numerical encoding format to eliminate comparison deviations caused by differences in data types and ensure the consistency of logical judgment processing.

[0149] In the arithmetic logic unit of the trusted execution environment, the precise Hamming distance value of the fixed-length code and the standard tolerance parameter of the fixed-length code are sent to the comparison operation module to perform logical judgment processing of size comparison, and the Boolean value signal is directly output by the condition selection circuit.

[0150] After the comparison operation module completes its processing, it writes the Boolean value signal into the temporary status register of this step, and maps the Boolean value signal into a Boolean verification result flag bit that represents the compliance of identity migration according to the Boolean enumeration rules of the consortium blockchain judgment protocol.

[0151] By executing the above chained processing, the accurate Hamming distance result of the previous step is transformed into compliance judgment data that can be directly called by subsequent seamless migration or re-authentication processes, thereby achieving dynamic adaptation of identity binding relationships based on the degree of hardware feature drift.

[0152] For example, in a pharmaceutical logistics node equipment upgrade scenario, the precise Hamming distance calculated in the previous steps is 4, and the fingerprint tolerance threshold parameter configured in the consortium blockchain consensus strategy is 6. These two values ​​are converted to 16-bit fixed-length binary codes: 0000000000000100 and 0000000000000110, respectively. The size comparison logic is executed in the comparison operation module of the trusted execution environment, and its formula can be expressed as: H≤T, where H is the precise Hamming distance value and T is the fingerprint tolerance threshold parameter. Substituting the example values, 4≤6 is true, and the comparison outputs a Boolean signal TRUE. According to the consortium blockchain judgment protocol enumeration rules, this Boolean signal is mapped to the compliance flag bit "1". After executing this step, the system will directly enter the seamless migration path of S7.4, significantly improving the real-time performance of node binding relationship updates and avoiding time-consuming re-authentication processes in this case.

[0153] S7.4: When the Boolean verification result flag indicates that the tolerance condition is met, the new node capability fingerprint is extracted and subjected to one-way hash mapping transformation to generate a new anchor hash value for updating on-chain metadata, thereby achieving seamless migration of identity binding relationship.

[0154] Perform a read operation on the Boolean verification result flag output by step S7.3, and use the flag state that meets the tolerance threshold condition as the execution trigger condition for this sub-step, and clarify that the input object is the new node capability fingerprint and its binary serialization result.

[0155] The new node capability fingerprint is invoked by a pre-built one-way hash mapping algorithm engine. An input buffer is configured in a trusted execution environment and a standardized fingerprint byte stream is written to it, so that the algorithm runs in hardware isolation mode to prevent data interception in the middle.

[0156] In the hash mapping process, the hash iteration rounds and bit permutation modes are set, and bit shifting, logical XOR and modular addition operations are performed to eliminate local correlation of input data and ensure that the result has anti-collision and irreversible characteristics.

[0157] The results of the above hash iteration operation are length-fixed using national cryptographic standards or internationally accepted standards to ensure that the output hash value meets the byte length and encoding rules defined in the on-chain metadata field, thus obtaining a new anchor hash value.

[0158] The generated new anchor hash value is associated with the current decentralized digital identity identifier of the drug. The on-chain metadata update interface is called to overwrite the original anchor hash field with the hash value, and the hash value is submitted to the consortium blockchain consensus mechanism for write confirmation, so as to realize the seamless migration of identity binding relationship in heterogeneous node environment.

[0159] By using a one-way hash mapping process, the verification result of the previous step is transformed into a new anchor hash value that can be updated on the chain, so as to realize the real-time adjustment of the drug identity binding relationship in the scenario of node capability fingerprint change without affecting system consistency.

[0160] For example, after a hardware upgrade, the new node capability fingerprint of a cold chain transport vehicle terminal, after binary serialization, is 128 bytes long. It is input into a trusted execution environment to call the SHA3-256 algorithm, configured with 64 iteration rounds, a 7-bit circular left shift mode, a fixed seed code of 0x5A5A5A5A for the XOR mask, and a modulo-base of 256. The 256-bit result output after the hash operation meets the length requirement of the on-chain metadata field and overwrites the original anchor hash field through the on-chain metadata update interface. After the consensus node of the consortium blockchain confirms the write, the binding relationship between the cold chain vehicle terminal and the digital identity of the medicine is seamlessly migrated. In this scenario, the formula for calculating the anchor hash value can be expressed as: Here, H represents the new anchor hash value, D is the standardized byte stream of the new node capability fingerprint, RotateLeft(D,7) indicates a 7-bit cyclic left shift operation, and M is a fixed seed code mask value. These parameters ensure that the new anchor hash value possesses collision resistance and irreversibility. During on-chain verification, this update process significantly improves the security and performance stability of drug digital identity migration in heterogeneous node environments.

[0161] S7.5: When the Boolean verification result flag indicates that the tolerance condition is not met, a re-authentication trigger instruction is constructed based on the deviation state of the accurate Hamming distance value exceeding the threshold, so as to start the minimum re-authentication process of receiving the three most recent block header hashes and signatures to complete the dynamic identity reconstruction in the heterogeneous node environment.

[0162] For the state where the Boolean verification result flag generated by the preceding step S7.3 does not meet the tolerance condition, the input objects include the precise Hamming distance value, the preset fingerprint tolerance threshold, and the node capability fingerprint bit sequence. A re-authentication trigger logic dependent on drift exceeding the limit is executed. Based on the difference state exceeding the threshold, the re-authentication trigger generation function is called through the drift degree data to form an instruction message containing the node identity reconstruction request code, along with the original fingerprint generation timestamp and the current drift coefficient as metadata parameters. The instruction message is transmitted to the node authentication management module via the consortium blockchain security control channel, initiating the minimal re-authentication workflow instantiation operation. It specifies that the three most recent block header hashes and corresponding digital signatures must be collected as the unique verification input set. The re-authentication process configuration file is loaded within the authentication management module, setting the collection window size to the three consensus participation records and limiting the time span to no more than the maximum allowed multiple of the standard on-chain block production cycle. Data queuing rules are established to ensure that data is submitted to the verification module in the order of the generated timestamps. The re-authentication workflow's internal state machine establishes a temporary state identifier for the current node's identity rebinding process. The collected block header hash and signature data are associated with the original drift state identifier to ensure data integrity and traceability. Through this processing, the drift determination result from the previous step is transformed into an executable re-authentication trigger instruction, enabling precise triggering of the dynamic reconstruction initiation conditions for node capability fingerprints in heterogeneous device environments.

[0163] For example, after the hardware encryption module of the cold chain transport vehicle's on-board terminal is updated, the precise Hamming distance between its new node capability fingerprint and the fingerprint corresponding to the original anchor hash is calculated to be 7. The preset fingerprint tolerance threshold is 3, and the drift coefficient is calculated as 7 / 24, where the denominator represents the total bit length of the node capability fingerprint. Exceeding the difference limit triggers the re-authentication generation function, outputting the re-authentication request code "RR-HT7-TS1692300000", along with the drift coefficient and the original generation timestamp. This is sent to the node authentication management module via the consortium blockchain security channel. This module calls the configuration file to determine the collection of the hashes and signatures of the three most recent consensus blocks. Its collection window is limited to three records, and the time span does not exceed five times the block generation cycle. In this embodiment, the block header hashes submitted by the vehicle node are H1, H2, and H3, and the signatures are Sig1, Sig2, and Sig3, all enqueued in chronological order and associated with the drift state identifier ID-PL0001. After receiving the above data, the verification module can continue to perform identity legitimacy and chain integrity verification according to the re-authentication workflow requirements. Finally, when the legitimacy conditions are met, the new anchor point registration is realized, ensuring that the digital identity of the drug still has the reliable continuity of on-chain traceability even when the vehicle terminal hardware configuration changes.

[0164] Step S8: Based on the three most recent successful block header hashes and signatures submitted by the receiving node in the minimized re-authentication process, and after the on-chain lightweight verification module confirms the continuity of historical behavior, the new anchor registration is approved, completing the dynamic decoupling and reconstruction of the drug digital identity in a heterogeneous node environment. Specifically, this includes: S8.1: Based on the instruction to trigger the minimized re-authentication process, obtain the block header hash sequence and corresponding digital signature data generated in the three most recent successful participations in the consensus process from the local secure storage area of ​​the logistics node to be authenticated, and encapsulate the block header hash sequence and digital signature data into a re-authentication request payload to construct an initial verification input set containing the node's historical behavior credentials.

[0165] S8.2: Perform asymmetric encryption verification on the digital signature data in the re-authentication request payload, use the pre-built root public key certificate library of the consortium blockchain to restore the node identity of the signing private key, and compare the restored node identity with the source node information in the re-authentication request payload to generate an identity verification pass flag that represents the legality of the signature.

[0166] S8.3: Based on the identity verification pass flag, call the on-chain lightweight verification module to read the historical block index stored in the consortium chain ledger, and perform a bit-by-bit matching operation between the block header hash sequence in the re-authentication request payload and the official record in the historical block index to generate a chain integrity verification result that represents the authenticity of the block data.

[0167] S8.4: Based on the chain integrity verification result, extract the timestamps of three consecutive block generation and calculate the time interval variance between adjacent timestamps. Perform logical judgment processing on the time interval variance and the normal block production fluctuation threshold specified by the consortium chain consensus protocol to generate a temporal coherence evaluation index that characterizes the continuity of node participation behavior.

[0168] S8.5: Based on the time sequence coherence evaluation index reaching the preset continuity standard, the anchor point update state machine in the smart contract is triggered, the newly generated node capability fingerprint hash value is written into the drug digital identity metadata field and the old anchor point is marked as invalid, so as to complete the dynamic decoupling of drug digital identity and the new anchor point registration and reconstruction in the heterogeneous node environment.

[0169] In one embodiment, a blockchain-based trusted traceability system for the entire pharmaceutical logistics chain is provided, comprising: a module for acquiring original hardware resource data, a module for acquiring node capability fingerprints, a module for constructing spatiotemporal entropy sources, a module for acquiring decentralized digital identity identifiers, a module for acquiring anchor hash values, a module for acquiring edit distance values, a module for updating anchor hash values, and a module for registering new anchor points, wherein: Raw hardware resource data acquisition module: used to send lightweight probe packets to the logistics nodes to be connected to the consortium blockchain, triggering the nodes to perform local resource detection and acquire the nodes' raw hardware resource data; Node capability fingerprint acquisition module: used to perform standardized encoding processing based on the original hardware resource data, and to concatenate the encoding result with the hash of the unified social credit code suffix of the enterprise to which the node belongs to generate a node capability fingerprint; Spatiotemporal entropy source construction module: used to fuse drug batch information with the UTC microsecond-level timestamp broadcast by the regulatory platform and the Beidou time synchronization deviation compensation value to construct a spatiotemporal entropy source; Decentralized digital identity identifier acquisition module: used to initiate a distributed key derivation protocol using a trusted execution environment, using the node capability fingerprint as the root key and the spatiotemporal entropy source as the salt value to perform multiple rounds of lightweight hash iteration, generate a drug-specific private key and simultaneously derive a decentralized digital identity identifier; Anchor Hash Value Acquisition Module: Used to perform hash operations on the node capability fingerprint to generate an anchor hash value, and write the anchor hash value into the on-chain registration transaction containing the decentralized digital identity identifier; Edit distance value acquisition module: When a node device change is detected, resulting in a new node capability fingerprint, the module calculates the Hamming distance between the new node capability fingerprint and the node capability fingerprint corresponding to the original anchor hash value, and generates an edit distance value. Anchor Hash Value Update Module: Used to update the anchor hash value stored in the on-chain registered transaction if the edit distance value is less than or equal to a preset tolerance threshold; New Anchor Point Registration Module: If the edit distance value is greater than the preset tolerance threshold, it triggers the minimized re-authentication process and completes the registration of the new anchor point in the on-chain registration transaction.

[0170] This application provides a blockchain-based, end-to-end trusted traceability method for pharmaceutical logistics, which can be applied to, for example... Figure 4 In the application environment shown, terminal 102 communicates with server 104 via a network. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices, and server 104 can be a standalone server or a server cluster consisting of multiple servers.

[0171] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores data generated during the implementation of a blockchain-based trusted traceability method for the entire pharmaceutical logistics chain. The network interface communicates with external terminals via a network. When the processor executes the computer program, it implements a blockchain-based trusted traceability method for the entire pharmaceutical logistics chain.

[0172] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: S1: Send a lightweight probe packet to the logistics node to be connected to the consortium blockchain, triggering the node to perform local resource detection and obtain the node's original hardware resource data; S2: Based on the original hardware resource data, perform standardized encoding processing, and concatenate the encoding result with the hash of the unified social credit code suffix of the enterprise to which the node belongs to generate the node capability fingerprint; S3: The drug batch information is fused with the UTC microsecond-level timestamp broadcast by the regulatory platform and the Beidou time synchronization deviation compensation value to construct a spatiotemporal entropy source; S4: Utilize a trusted execution environment to initiate a distributed key derivation protocol, using the node capability fingerprint as the root key and the spatiotemporal entropy source as the salt value to perform multiple rounds of lightweight hash iterations, generate a drug-specific private key and simultaneously derive a decentralized digital identity identifier. S5: Perform a hash operation on the node capability fingerprint to generate an anchor hash value, and write the anchor hash value into an on-chain registration transaction containing the decentralized digital identity identifier; S6: When a change in a node device is detected, resulting in the generation of a new node capability fingerprint, the Hamming distance between the new node capability fingerprint and the node capability fingerprint corresponding to the original anchor hash value is calculated, and an edit distance value is generated. S7: If the edit distance value is less than or equal to the preset tolerance threshold, then update the anchor hash value stored in the on-chain registered transaction; S8: If the edit distance value is greater than the preset tolerance threshold, the minimized re-authentication process is triggered and the new anchor point registration in the on-chain registration transaction is completed.

[0173] For those skilled in the art, various other corresponding changes and modifications can be made based on the technical solutions and concepts described above, and all such changes and modifications should fall within the protection scope of the claims of this invention.

[0174] Unless otherwise defined, the technical or scientific terms used herein shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains. The terms “first,” “second,” “third,” and similar terms used in this patent application specification and claims do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, the terms “an” or “a” and similar terms do not indicate a quantity limitation, but rather indicate the presence of at least one. The terms “comprising” or “including” and similar terms mean that the elements or objects preceding “comprising” or “including” encompass the elements or objects listed following “comprising” or “including” and their equivalents, and do not exclude other elements or objects. The “multiple” mentioned in the embodiments of this application refers to two or more. A and / or B indicate three possibilities: A; B; and A and B.

[0175] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and such modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A blockchain-based pharmaceutical logistics full-chain credible traceability method, characterized in that, Specifically, it includes: S1: Send a lightweight probe packet to the logistics node to be connected to the consortium blockchain, triggering the node to perform local resource detection and obtain the node's original hardware resource data; S2: Based on the original hardware resource data, perform standardized encoding processing, and concatenate the encoding result with the hash of the unified social credit code suffix of the enterprise to which the node belongs to generate the node capability fingerprint; S3: The drug batch information is fused with the UTC microsecond-level timestamp broadcast by the regulatory platform and the Beidou time synchronization deviation compensation value to construct a spatiotemporal entropy source; S4: Utilize a trusted execution environment to initiate a distributed key derivation protocol, using the node capability fingerprint as the root key and the spatiotemporal entropy source as the salt value to perform multiple rounds of hash iteration, generate a drug-specific private key, and simultaneously derive a decentralized digital identity identifier. S5: Perform a hash operation on the node capability fingerprint to generate an anchor hash value, and write the anchor hash value into an on-chain registration transaction containing the decentralized digital identity identifier; S6: When a change in a node device is detected, resulting in the generation of a new node capability fingerprint, the Hamming distance between the new node capability fingerprint and the node capability fingerprint corresponding to the original anchor hash value is calculated, and an edit distance value is generated. S7: If the edit distance value is less than or equal to the preset tolerance threshold, then update the anchor hash value stored in the on-chain registered transaction; S8: If the edit distance value is greater than the preset tolerance threshold, the minimized re-authentication process is triggered and the new anchor point registration in the on-chain registration transaction is completed.

2. The blockchain-based trusted traceability method for the entire pharmaceutical logistics chain according to claim 1, characterized in that, In S4, the number of iterations for performing multiple rounds of hash iteration using the node capability fingerprint as the root key and the spatiotemporal entropy source as the salt value is 8.

3. The blockchain-based trusted traceability method for the entire pharmaceutical logistics chain according to claim 1, characterized in that, Step S3 specifically includes: Standardized serialization encoding is performed on the batch information of drugs in the drug outbound process to extract key field sequences and generate basic batch feature vectors; Based on the basic batch feature vector, the UTC microsecond-level timestamp data is obtained by accessing the broadcast interface of the regulatory platform, and the UTC microsecond-level timestamp data is subjected to nanosecond-level jitter filtering to generate calibration time reference parameters. Receive the original satellite timing signal, calculate the clock deviation value between the original satellite timing signal and the calibration time reference parameter, and generate the BeiDou timing deviation compensation value; The basic batch feature vector, the calibration time reference parameter and the BeiDou timing deviation compensation value are multidimensionally spliced ​​and fused, and a single round of hash compression operation is performed to generate an initial fusion summary data block. The initial fusion summary data block is subjected to secondary entropy enhancement obfuscation processing, and the spatiotemporal entropy source is output by XORing and superimposing the environmental noise seed code released by the National Time Service Center on the same day.

4. The blockchain-based trusted traceability method for the entire pharmaceutical logistics chain according to claim 3, characterized in that, The key field sequence includes: National Drug Approval Number, Production Date Stamp, and Expiry Date.

5. The blockchain-based trusted traceability method for the entire pharmaceutical logistics chain according to claim 1, characterized in that, Step S4 specifically includes: In a trusted execution environment, memory isolation mapping is performed on the byte sequence of the node capability fingerprint and the random bit stream of the spatiotemporal entropy source to obtain the root key seed and dynamic salt value parameters. The root key seed is used as the initial input vector and XORed with the dynamic salt value parameter to generate an intermediate derived key stream, thereby obtaining a high-entropy private factor sequence for subsequent asymmetric encryption operations. Elliptic curve scalar multiplication is performed on the high-entropy private factor sequence. A preset pharmaceutical consortium chain-specific generator point is selected as the reference coordinate. The corresponding public key coordinate point pair is calculated and the private key value is solidified to obtain the drug-specific key. The private key value is only stored inside the trusted execution environment. Based on the public key coordinate point pairs in the drug-specific key, feature hash fragments are extracted, and structured splicing and assembly processing is performed by combining the standard encoded string of the drug batch number, the truncated check code of the node capability fingerprint, and the cyclic redundancy check value of the timestamp to construct a four-segment identity encoded string and obtain the decentralized digital identity identifier.

6. The blockchain-based trusted traceability method for the entire pharmaceutical logistics chain according to claim 1, characterized in that, Step S5 specifically includes: The node capability fingerprint is processed by binary serialization encoding, and the original hardware resource data is converted into a standard byte stream format to obtain a standardized fingerprint data block; Based on the standardized fingerprint data block, a one-way hash transformation operation is performed. Through multiple rounds of bit permutation and modulo addition operations, local data correlation is eliminated to generate the anchor hash value. The anchor hash value is mapped to the payload field of the on-chain transaction using the predefined metadata encapsulation protocol of the smart contract, and associated with the decentralized digital identity identifier of the current drug to construct a transaction object to be signed containing identity binding relationship, forming an on-chain registration request data packet; Based on the consensus node of the consortium blockchain, the on-chain registration request data packet is digitally signed and formatted for compliance. After confirming the transaction initiator's authority and the integrity of the data structure, the metadata field containing the anchor hash value is permanently written into the block body of the distributed ledger to generate an immutable on-chain registration transaction record. A bidirectional mapping index table is established between the anchor hash value and the decentralized digital identity identifier of the drug based on the block height and transaction hash index of the on-chain registered transaction records.

7. The blockchain-based trusted traceability method for the entire pharmaceutical logistics chain according to claim 1, characterized in that, The original hardware resource data includes: encryption algorithm support types, millisecond-level jitter range levels, and three-level encoding storage throughput capabilities; The triggering node performs local resource detection, including at least one of the following detection tasks: performing an encryption instruction set availability scan, memory page allocation response latency sampling, and local non-volatile storage random write throughput estimation.

8. A blockchain-based, end-to-end trusted traceability system for pharmaceutical logistics, characterized in that, include: Raw hardware resource data acquisition module: used to send lightweight probe packets to the logistics nodes to be connected to the consortium blockchain, triggering the nodes to perform local resource detection and acquire the nodes' raw hardware resource data; Node capability fingerprint acquisition module: used to perform standardized encoding processing based on the original hardware resource data, and to concatenate the encoding result with the hash of the unified social credit code suffix of the enterprise to which the node belongs to generate a node capability fingerprint; Spatiotemporal entropy source construction module: used to fuse drug batch information with the UTC microsecond-level timestamp broadcast by the regulatory platform and the Beidou time synchronization deviation compensation value to construct a spatiotemporal entropy source; Decentralized digital identity identifier acquisition module: used to initiate a distributed key derivation protocol using a trusted execution environment, using the node capability fingerprint as the root key and the spatiotemporal entropy source as the salt value to perform multiple rounds of lightweight hash iteration, generate a drug-specific private key and simultaneously derive a decentralized digital identity identifier; Anchor Hash Value Acquisition Module: Used to perform hash operations on the node capability fingerprint to generate an anchor hash value, and write the anchor hash value into the on-chain registration transaction containing the decentralized digital identity identifier; Edit distance value acquisition module: When a node device change is detected, resulting in a new node capability fingerprint, the module calculates the Hamming distance between the new node capability fingerprint and the node capability fingerprint corresponding to the original anchor hash value, and generates an edit distance value. Anchor Hash Value Update Module: Used to update the anchor hash value stored in the on-chain registered transaction if the edit distance value is less than or equal to a preset tolerance threshold; New Anchor Point Registration Module: If the edit distance value is greater than the preset tolerance threshold, it triggers the minimized re-authentication process and completes the registration of the new anchor point in the on-chain registration transaction.

9. A computer device, characterized in that, include: A processor, a memory, and a computer program stored in the memory and executable on the processor; the computer program, when executed by the processor, implements the steps of the blockchain-based trusted traceability method for the entire pharmaceutical logistics chain as described in any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium stores a computer program, which, when executed by a processor, implements the steps of the blockchain-based trusted traceability method for the entire pharmaceutical logistics chain as described in any one of claims 1 to 7.

Images