Logistics information tamper-proofing system based on block chain

Abstract

The invention relates to the technical field of logistics information tampering prevention, in particular to a logistics information tampering prevention system based on a block chain, and the system comprises a logistics information initial encryption module which is used for collecting key logistics information items, calling a chameleon hash function to carry out the hash operation of the collected key logistics information items, obtaining a logistics information chameleon hash sequence, and sending the logistics information chameleon hash sequence to a logistics information tampering prevention module; and a warehouse administrator or a carrier driver uses a private key to digitally sign the key logistics information item and the logistics information chameleon hash sequence to generate a signed logistics data packet. According to the method, key logistics information items are collected, and a chameleon hash function is adopted to perform hash operation on logistics information, so that the tamper-proof capability of the information in the transmission process is enhanced; meanwhile, a private key is used for carrying out digital signature to bind the identity of an operator, so that the identity traceability of an information source is realized, and the identity is effectively prevented from being counterfeited or falsely used.

Description

Technical Field

[0001] The present invention relates to the technical field of logistics information tamper-proofing, and in particular to a logistics information tamper-proofing system based on blockchain. Background Art

[0002] The field of logistics information anti-tampering technology is a key information technology field that focuses on the security and trusted management of logistics supply chain data. It covers security protection mechanisms for various aspects of logistics information collection, storage, transmission, verification, updating and auditing. With cryptography technology, digital signature technology, trusted timestamp technology and distributed ledger technology as the core support, it forms a series of technical systems that ensure that logistics data cannot be tampered with without authorization, is easy to trace and verify, and has transparency and credibility.

[0003] Existing technologies lack in-depth safeguards for the temporal consistency and identity binding mechanisms of logistics information. This can lead to poor timeliness of logistics information and the vulnerability of data records to tampering or falsification in actual operations. For example, when a logistics event arises, the lack of a strict delay mechanism for information recording can lead to disagreements among the parties regarding the timing of the event, making it difficult to definitively determine responsibility within the logistics process and hindering the effective resolution of logistics disputes. Furthermore, existing technologies lack a clear understanding of the correlations between logistics events, lacking a clear logical dependency structure. This results in poor timeliness for auditing and tracing logistics events, unclear dependencies between related events, and difficulty in quickly and efficiently tracing and tracing abnormal events or illegal activities. Therefore, improvements are needed. Summary of the Invention

[0004] The purpose of this invention is to solve the shortcomings of the existing technology and propose a blockchain-based logistics information tamper-proof system.

[0005] To achieve the above objectives, the present invention adopts the following technical solutions: A blockchain-based logistics information tamper-proof system includes:

[0006] The logistics information initial encryption module collects key logistics information items, calls the chameleon hash function to perform hash operations on the collected key logistics information items, and obtains a logistics information chameleon hash sequence. The warehouse manager or carrier driver uses the private key to digitally sign the key logistics information items and the logistics information chameleon hash sequence to generate a signed logistics data packet;

[0007] The timestamp trusted anchor module extracts the logistics information hash value from the signed logistics data packet as the input for the verifiable delay function operation, obtains the VDF operation verification value, combines the VDF operation verification value with the chameleon hash value in the signed logistics data packet, performs a hash check on the combination result, and submits the check result and the combination value together to the blockchain for recording, thereby obtaining a blockchain anchor record with a time sequence;

[0008] The voucher event verification module, based on the logistics event description information submitted by the participating entities, constructs the logistics event description information into a new node of a directed acyclic graph, obtains the authenticated event node data, and links the authenticated event node data to the directed acyclic graph to form a logistics event dependency graph;

[0009] The information update traceability verification module is based on the compliance update of the logistics information in the logistics event dependency graph. The authorized holder submits the corresponding trapdoor key parameters, combines the trapdoor key parameters with the new logistics information to jointly calculate and generate a new chameleon hash input, obtains the verified updated information certificate, executes the data audit process, associates the verified updated information certificate with the target node in the logistics event dependency graph, and establishes a tamper-proof logistics information traceability path.

[0010] Preferably, the steps for obtaining the logistics information chameleon hash sequence are:

[0011] Collect the cargo batch number, shipping order number, and operation time, and write the three field values ​​into the structured data input form. Then verify the alphanumeric format of the cargo batch number, the fixed prefix rule of the shipping order number, and the UTC timestamp of the operation time. If all verification results pass, write the three fields into the logistics information field mapping structure as sequential key-value pairs to generate structured key logistics information items.

[0012] Based on the structured key logistics information item, the field values ​​of the cargo batch number, transport order number, and operation time are spliced ​​according to the format to construct an ASCII encoded string, which is imported as an input item into the Chameleon Hash function for processing. The structured key pair of the Chameleon Hash function is called to initialize the internal state parameters and then perform a one-way hash mapping process to output a hash digest sequence of constant length to generate an initial Chameleon Hash digest value;

[0013] The initial chameleon hash summary value is field-coupled with the structured key logistics information item to construct a data structure with a signature preprocessing identifier. The chameleon hash summary value is embedded in the hash field area of ​​the structure, and additional fields are written to describe the source module, timestamp number and summary generation batch number. This serves as a reproducible traceability infrastructure to generate a logistics information chameleon hash sequence.

[0014] Preferably, the steps for obtaining the signed logistics data packet are:

[0015] Call the private key information corresponding to the warehouse manager or carrier driver to complete the permission verification and key activation of the current operator's identity, write the key binding information and the corresponding identity code into the digital signature preparation structure, and generate the signature execution preparation item;

[0016] Based on the signature execution preparation item, the structured key logistics information item and the logistics information chameleon hash sequence are field-concatenated in a preset data order, and a unified message body is constructed as the input source data to be signed. The private key is loaded, and the elliptic curve encryption signature is executed on the input source data to obtain a digital signature object with an encrypted signature field;

[0017] Based on the digital signature object, the signature field, the original structured key logistics information item, the logistics information chameleon hash sequence and the signature executor identity are uniformly encapsulated into the data packet main structure, and the operation timestamp and data integrity check field are configured to generate a signed logistics data packet.

[0018] Preferably, the steps for obtaining the VDF operation verification value are:

[0019] Retrieve the field mapping structure in the signed logistics data packet, parse the field where the logistics information chameleon hash sequence is located field by field, convert the field value into hash format encoded text, verify the integrity of the encoding format, extract the logistics information chameleon hash sequence as the logistics information hash value, and obtain the logistics information hash value;

[0020] Based on the logistics information hash value, it is loaded as an input into the verifiable delay function, the execution context environment is configured and the forced delay parameters are set, the number of iterative calculations, the minimum clock interval and the execution duration are set, the verifiable delay function operation is started, and the verifiable delay function execution control object is generated;

[0021] Based on the verifiable delay function execution control object, the iterative one-way mapping operation is continuously performed until the preset time interval is reached and the operation is completed, the final value of the hash sequence stored in the computing node is extracted as the verification identifier, and the VDF operation verification value is generated.

[0022] Preferably, the steps for obtaining the time-series blockchain anchor record are:

[0023] Read the chameleon hash value content in the hash field area of ​​the signed logistics data packet, and call the VDF operation verification value, put the chameleon hash value in the first position and the VDF operation verification value in the last position in the field order to construct a joint structure, merge them to generate a complete combined input content, and generate a combined value of the VDF operation verification value and the chameleon hash value;

[0024] Based on the combined value of the VDF operation verification value and the chameleon hash value, the combined value is imported and a consistent hash operation is performed. The hash digest is calculated as the verification fingerprint, and then compared with the initial field structure to verify the consistency of the content. The result digest of the hash operation and the combined value body are recorded as the data pair to be uploaded to the chain, and the hash verification result and the data pair to be uploaded to the chain are generated;

[0025] Based on the hash verification result and the data pair to be uploaded to the chain, the hash verification result in the data pair is used as the verification field and the combined value is used as the anchor content field and written into the content area of ​​the current block, and the generation timestamp, identity code and block index number are attached. The writing process is completed through node consensus to generate a blockchain anchor record with time sequence.

[0026] Preferably, the steps for obtaining the logistics event dependency graph are:

[0027] Parse the event timestamp, location code, and event type fields in the logistics event description information node, convert them into a unified standard structure format, extract the corresponding fields in the previous event node, combine the maximum time span, maximum location code difference, and event type identification value range defined in the data dictionary, form a standardized processing basic set, and generate a field mapping set;

[0028] Based on the field mapping set, dimensionless normalization is performed on the time difference, location code difference and event type difference respectively, and the maximum normalization factor is used for normalization. The three types of differences are normalized and the fusion fitness of the logistics event node is calculated;

[0029] Based on the fusion fitness, all preceding event nodes that make the fusion fitness less than the maximum allowable fitness threshold set by the system are determined to be dependent valid nodes, a directed graph link relationship is established between the logistics event description information node and the preceding event node, and the corresponding fusion fitness is written in the edge weight field to complete the structure binding and node linking, and generate a logistics event dependency graph.

[0030] Preferably, the steps for obtaining the verified update information credential are:

[0031] Parse the logistics event dependency graph, verify the validity and permission level of the trapdoor key parameters submitted by the authorized holder, extract the original logistics information chameleon hash sequence from the signed logistics data packet, and form the hash benchmark of the data to be updated;

[0032] Based on the hash benchmark of the data to be updated, a hash input field is constructed in combination with the trapdoor key parameter and the new logistics information, and the inverse operation of the trapdoor mapping is performed on the hash benchmark of the data to be updated, so that the constructed hash input field is recalculated and a new logistics information chameleon hash sequence consistent with the hash benchmark of the data to be updated is generated, thereby generating a new chameleon hash input;

[0033] Based on the new chameleon hash input, the identity private key of the authorized holder is loaded, the new logistics information and the new chameleon hash input are digitally signed, encapsulated into a structured data certificate unit, and the signature generation timestamp and the identity of the authorized holder are written to obtain a verified updated information certificate.

[0034] Preferably, the steps for obtaining the tamper-proof logistics information traceability path are:

[0035] Extract the target hash summary field, submission timestamp field, and key usage record from the verified update information voucher, locate the target node corresponding to the voucher, and pull the blockchain anchor sequence of the target node in the logistics event dependency graph. At the same time, extract the block index call frequency in the last 30 days from the call chain access log to generate a target node data audit reference set;

[0036] Calculating a composite audit index based on the target node data audit reference set;

[0037] Based on the composite audit index, if the composite audit index is lower than the set maximum allowable value, the current voucher content will be written into the target node's attached record field, and the node will be synchronized to the latest index position, all reference paths and audit status will be updated, a closed-loop verification chain will be constructed, and a tamper-proof logistics information traceability path will be generated.

[0038] Compared with the prior art, the advantages and positive effects of the present invention are:

[0039] In the present invention, by collecting key logistics information items and using the chameleon hash function to perform hash operations on the logistics information, the tamper-proof ability of the information itself during the transmission process is enhanced; at the same time, the private key is used for digital signature to bind the operator's identity, so as to achieve identity traceability of the information source and effectively prevent identity forgery or impersonation; in the data recording stage, a verifiable delay function is introduced to calculate the logistics information hash value, and the mandatory set delay is used to ensure the accuracy of the temporal sequence of the information record and the non-forgeability, thereby improving the consistency between the logistics record and the actual business process; at the same time, the event description information is used to construct a directed acyclic graph node structure, establish a clear dependency relationship between nodes, and improve the logical transparency and audit convenience between logistics events; in addition, by introducing trapdoor key parameters and combining the characteristics of the chameleon hash function, information compliance updates are achieved without destroying the original hash consistency, which not only ensures the security and compliance of the information update, but also ensures the traceability of the information; then the updated information is verified through data audit association to form a logistics information traceability path, which enhances the transparency and traceability efficiency of the overall system, reduces the risk of tampering, and effectively meets the high requirements of logistics business security management and judicial audit. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1It is a system flow chart of the present invention. DETAILED DESCRIPTION

[0041] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0042] See also Figure 1 The present invention provides a technical solution: a blockchain-based logistics information tamper-proof system comprising:

[0043] The logistics information initial encryption module collects key logistics information items, calls the Chameleon hash function to perform hash operations on the collected key logistics information items, and obtains the logistics information Chameleon hash sequence. The warehouse manager or carrier driver uses the private key to digitally sign the key logistics information items and the logistics information Chameleon hash sequence to generate a signed logistics data packet;

[0044] The timestamp trusted anchor module, based on the signed logistics data packet, extracts the logistics information hash value as the input for the verifiable delay function operation, obtains the VDF operation verification value, combines the VDF operation verification value with the chameleon hash value in the signed logistics data packet, performs a hash check on the combined result, and submits the check result and the combined value together to the blockchain for recording, obtaining a blockchain anchor record with a time sequence;

[0045] The voucher event verification module, based on the logistics event description information submitted by the participating entities, constructs the logistics event description information into a new node of a directed acyclic graph, obtains the authenticated event node data, and links the authenticated event node data to the directed acyclic graph to form a logistics event dependency graph;

[0046] The information update traceability verification module is based on the compliance update of logistics information in the logistics event dependency graph. The authorized holder submits the corresponding trapdoor key parameters, combines the trapdoor key parameters with the new logistics information to jointly calculate and generate a new chameleon hash input, obtains the verified updated information certificate, executes the data audit process, and associates the verified updated information certificate with the target node in the logistics event dependency graph to establish a tamper-proof logistics information traceability path.

[0047] The steps to obtain the logistics information chameleon hash sequence are:

[0048] Collect the cargo batch number, shipping order number, and operation time, and write the three field values ​​into the structured data input form. Then verify the alphanumeric format of the cargo batch number, the fixed prefix rule of the shipping order number, and the UTC timestamp of the operation time. If all verification results pass, write the three fields into the logistics information field mapping structure as sequential key-value pairs to generate structured key logistics information items.

[0049] Based on the structured key logistics information items, the field values ​​of the cargo batch number, transport order number, and operation time are concatenated according to the format and constructed into an ASCII encoded string. This string is then imported as an input into the Chameleon Hash function for processing. The structured key pair of the Chameleon Hash function is called to initialize the internal state parameters and then a one-way hash mapping process is executed. The result is a hash digest sequence of constant length that is output to generate an initial Chameleon Hash digest value.

[0050] The initial chameleon hash summary value is field-coupled with the structured key logistics information item to construct a data structure with a signature preprocessing identifier. The chameleon hash summary value is embedded in the hash field area of ​​the structure, and additional fields are written to describe the source module, timestamp number and summary generation batch number. This serves as a reproducible traceability infrastructure to generate a logistics information chameleon hash sequence.

[0051] Specifically, after collecting the cargo batch number, transport order number and operation time, the system writes the original string values ​​of these three fields into an internal predefined structured data input form object, which temporarily stores this data for subsequent verification. Next, the system starts a strict verification process for each data in a predetermined order. First, for the cargo batch number, the system verifies its format based on a regular expression, such as "[AZ]{2}\d{8}[AZ]{3}$". The rule requires that the batch number must start with two uppercase letters, followed by eight digits, and end with three uppercase letters. For example, a legal batch number can be "SH12345678BJG". If the cargo batch number fails to match this preset format, the system will record a verification failure event and indicate the failure reason as "cargo batch number format does not match", followed by the transport order number. Verification uses a fixed prefix rule that must begin with "YSD-" and be followed by exactly 10 digits. This rule, such as "YSD-", is configured during system initialization and is derived from logistics business specifications or partner agreements. For example, a legal shipping order number is "YSD-0123456789". The system verifies the prefix and subsequent numeric portion of the string by checking the length and character type. Any non-compliance will result in a verification failure, with the reason recorded as "Invalid shipping order number prefix or length". Finally, the operation time is verified to ensure compliance with the international standard UTC timestamp. The specific format required is the ISO8601 extended format, namely "YYYY-MM-DDTHH:MM:SS.sssZ", for example, "2025-05-09T15:30:00.123Z", the system calls the built-in date and time parsing library, tries to convert the input operation time string strictly according to this format, and checks whether the converted time is a valid time point in the past or the present. For example, the time cannot be later than the current system time plus a small tolerance (such as 5 seconds, this tolerance is used to deal with possible small synchronization delays). If the parsing fails or the timestamp is ahead, the verification failure and the reason such as "incorrect operation time format" or "invalid operation timestamp" will be recorded. Only when all three key information mentioned above, namely the cargo batch number, transport order number and operation time, have successfully passed their respective verification logic, will the system continue to execute and save this time. The three verified field values ​​are written as key-value pairs into a newly created logistics information field mapping structure instance in the fixed order of "cargo batch number," "transportation order number," and "operation time." For example, the key is "cargo_batch_identifier," the value is the verified cargo batch number string, the key is "transport_document_id," the value is the verified transport order number string, and the key is "timestamp_of_operation," the value is the verified and normalized operation time string. After this structure is instantiated, a structured key logistics information item is generated.

[0052] Based on the structured key logistics information items generated in the previous step, the system first extracts the verified specific field values ​​of the cargo batch number, transport order number and operation time. Then, the system connects these values ​​according to a predefined splicing format. The splicing format specifies the order and separators of the fields. For example, the format is "the value of the cargo batch number" followed by a vertical bar separator "|", then "the value of the transport order number", another vertical bar separator "|", and finally "the value of the operation time". The value of the operation time will be uniformly converted into the compact format of "YYYYMMDDHHMMSSZ". For example, if the batch number is "SH12345678BJG", the transport order number is "YSD-0123456789", and the operation time is "

[0053] 2025-05-09T15:30:00.123Z", the concatenated string is "

[0054] SH12345678BJG|YSD-0123456789|20250509153000Z". Subsequently, the concatenated string is constructed into an ASCII-encoded byte sequence and imported into the processing flow of the Chameleon hash function as the core input message item. Before performing the hash operation, the system will call the structured key pair of the Chameleon hash function to initialize its internal state parameters. The key pair includes public parameters and the user's specific public key and the corresponding trapdoor (part of the private key). The public parameters are, for example, a large prime number P (for example, a 2048-bit prime number, which is selected based on the currently recommended cryptographic security standards), a P-1 large prime factor Q, and a cyclic group generator G of order Q. The user's public key contains Y=G X (modP), where X is the user's secret trapdoor information. The initialization process also includes securely generating a random number R for this hash operation. The length of R is equivalent to the number of bits in Q. After the initialization is completed, the system performs a one-way hash mapping process, combining the ASCII encoded string (as the message M) and the random number R, and calculating the hash value through the Chameleon Hash algorithm. The calculation process can be expressed as: Among them, h is the calculated initial Chameleon hash digest value, M is the ASCII encoded string to be hashed, R is the random number generated by this operation, G, Y and P are the public parameters of the Chameleon hash function and the user's public key, || represents the byte string splicing operation, and H0 is a standard cryptographic hash function, such as SHA-256, whose output is used as the exponent. The operation result h is a hash digest sequence of constant length, whose length depends on the size of the modulus P. For example, for a 2048-bit P, the result is also a 2048-bit integer, usually expressed as 512 hexadecimal characters. This output sequence is the generated initial Chameleon hash digest value.

[0055] After logically coupling the initial Chameleon hash digest value generated in the previous step with the structured key logistics information items generated in the first step, the system begins to construct a data structure with a signature preprocessing identifier. The signature preprocessing identifier is a fixed string constant, such as "LOGIS_CH_PREPROC_V1.0". Its value is defined during system deployment and is used to indicate the type and version of this data structure. During the construction of this data structure, the system defines a series of clear fields for it. One key field, such as "chameleon_digest_field", is specifically used to embed the initial Chameleon hash digest value calculated by the Chameleon hash function (i.e., h from the previous step, stored as a hexadecimal string). In addition to the hash value itself, the system also writes several additional descriptive and traceability fields to the data structure, including a source module identifier, whose value is selected from a preset module code list, such as "WM_INPUT_SYS_002". This list contains all system module codes that may generate this type of data. The specific code value is automatically filled in based on the system component where the current operation occurs. The setting of this preset list refers to the system design during the system design. The division and coding specifications of each functional module also include a timestamp number, which is a serial number generated to ensure the uniqueness of the record. For example, the number may be based on the current date and a self-incrementing counter for the day, such as "2025050910350000001", where "202505091035" represents the year, month, day, hour, and minute, followed by a 7-digit self-incrementing sequence. The generation rule is to read the current sequence maximum value and add one each time a summary is created. This rule ensures that the summary generated within the same minute also has a unique number. Then write a summary generation batch number, such as "BATCH_MAY 092025_005". This number is used to group the summaries generated within a certain time window or business cycle into a batch. The setting rule is to generate a new batch number every day, which also includes a batch sequence number within that day. These additional fields, together with the previously embedded chameleon hash digest value and the coupled structured key logistics information items (which themselves contain the cargo batch number, transport order number, and operation time), constitute a complete data entity that can serve as the basis for subsequent reproducible traceability processes. The resulting data structure, such as a JSON object containing all the above fields, is identified as a logistics information chameleon hash sequence.

[0056] The steps to obtain the signed logistics data package are:

[0057] Call the private key information corresponding to the warehouse manager or carrier driver to complete the permission verification and key activation of the current operator's identity, write the key binding information and the corresponding identity code into the digital signature preparation structure, and generate the signature execution preparation item;

[0058] Based on the signature execution preparation item, the structured key logistics information item and the logistics information chameleon hash sequence are cascaded in the preset data order, and a unified message body is constructed as the input source data to be signed. The private key is loaded and the elliptic curve encryption signature is executed on the input source data to obtain a digital signature object with an encrypted signature field.

[0059] Based on the digital signature object, the signature field, original structured key logistics information items, logistics information chameleon hash sequence and signature executor identity are uniformly encapsulated into the main structure of the data packet, and the operation timestamp and data integrity check fields are configured to generate a signed logistics data packet.

[0060] Specifically, after calling the private key information corresponding to the warehouse manager or carrier driver, the system first identifies the current operator's identity code based on the current operation session or the work credentials provided by the operator (for example, employee number or login token), for example, "Driver Zhang San's identity code is SJ00768". Then, the system performs a strict permission verification process, comparing this identity code with the preset access control list (ACL) or role library. The ACL is configured by the authorized administrator during the system deployment phase, and defines in detail the set of operations that each identity code or role is allowed to perform. For example, the ACL may include Containing the entry "Identity code: SJ00768, allowed operations: [generate logistics signature, query transportation tasks]", if the currently requested operation (i.e., generate digital signature) exists in the list of allowed operations of the identity code, and the operator account status is normal (for example, not disabled or marked as suspicious), the permission verification passes. If it fails, the operation is immediately terminated and the permission abnormality event is recorded. After the permission verification is successful, the key activation phase begins. The system prompts the operator to enter the activation password of their private key, such as a complex password of at least 8 characters containing uppercase and lowercase letters, numbers, and special symbols, or The user requests biometric verification (such as fingerprint) through the connected hardware security module (such as USBKey or smart card). The successful activation password or biometric verification will be used to decrypt the user's private key stored in the secure medium. The private key is always encrypted in a static state, for example, using the AES-256 algorithm. The number of activation attempts will be limited. For example, if the wrong password is entered three times in a row, the account's key usage permission will be temporarily locked for 30 minutes. This threshold (3 attempts) and lockout duration (30 minutes) are set according to the security policy, which takes into account the security of preventing brute force cracking. To meet the security requirements and user operation convenience, after successfully activating the private key, the system will write the key binding information associated with the private key, such as the unique serial number or fingerprint of the public key certificate corresponding to the private key (for example, "certificate serial number: 0A:1B:2C:3D:4E:5F"), together with the verified current operator identity code ("SJ00768"), into a newly created memory data structure, namely the digital signature preparation structure. The structure will also record the permission verification result as "passed" and the key activation status as "successful". This digital signature preparation structure constitutes the signature execution preparation item.

[0061] After executing the preparation items based on the signature generated in the previous step and confirming that the operator authority and key have been activated, the system then obtains the generated "Logistics Information Chameleon Hash Sequence" and the generated "Structured Key Logistics Information Item" from the previous process. The system strictly selects and concatenates specific fields in the two data structures according to a preset data order. For example, the preset order stipulates that the serialized string of the "Structured Key Logistics Information Item" is first, followed by a specific separator (such as "&&&FIELD_SEPARATOR&&&"), and then the serialized string of the "Logistics Information Chameleon Hash Sequence". This serialization adopts the normalized JSON format, that is, the keys are sorted in alphabetical order without unnecessary blanks to ensure that the data to be signed each time is exactly the same. Through this The system combines the two methods to construct a unified byte stream message body, which is the input source data to be signed. Subsequently, the system securely loads the activated operator private key from the signature execution preparation item. The private key is protected by a security mechanism in the memory. Then, the system performs an elliptic curve digital signature operation on the unified message body. The algorithm used is, for example, the SM2 elliptic curve algorithm that meets the standards recommended by the State Cryptography Administration, or the internationally widely used ECDSAP-256 curve with SHA-256 hash (the selection is based on the security level determined during system design, for example, P-256 provides a security strength of about 128 bits). The signing process first applies the SHA-256 hash algorithm to the input source data to be signed (that is, the aforementioned unified message body) to generate a 256-bit hash digest H, and then uses the loaded private key d A And a cryptographically secure random number k generated specifically for this signature operation (make sure the k value is different for each signature) is used to sign this hash summary H. The standard ECDSA signature process can be briefly described as follows: calculate the elliptic curve point kG = (x1, y1), where G is the base point of the selected curve, then the first component of the signature result r = x1 (modn), the second component s = k -1 (H+r·d A )(modn), where n is the order of the base point G. If r or s is 0, reselect k and calculate, (r, s) = Sign ECDSA (H,d A ,k), where H is the hash value of the input source data to be signed, d A is the signer's elliptic curve private key, k is a random number generated for this signature operation, and the signature algorithm ultimately outputs a digital signature field consisting of two parts (usually two large integers r and s). This signature field, together with the original data to be signed, constitutes a digital signature object with an encrypted signature field.

[0062] Based on the digital signature object generated in the previous link, which already contains the specific content of the data to be signed and the corresponding elliptic curve digital signature r and s values, the system begins to extract and integrate the core elements of the signature operation. Specifically, it extracts the digital signature field (i.e., the value of r and s, usually expressed as a hexadecimal string), the original structured key logistics information items obtained in the previous process (including initial collection information such as cargo batch number, transport order number and operation time), and the logistics information chameleon hash sequence also obtained in the previous process (including the initial chameleon hash summary value, a copy of the key logistics information items and related metadata), together with the signature executor identity obtained from the signature execution preparation item (for example, "SJ00768"), and encapsulates these information items into a newly defined data packet main structure. This structure uses JSON format, for example, and its internal fields have clear names and orders, such as "signer_id", "

[0063] During the encapsulation process, the system also configures two additional management fields for the main structure of the data packet. The first is the operation timestamp, which records the precise Universal Coordinated Time (UTC) when the current encapsulation operation is completed, such as "2025-05-09T15:45:10.550Z", using the ISO8601 standard format. The second is the data integrity check field. The value of this field is the hash value calculated by serializing all other contents of the entire main structure of the data packet (before filling this check field) (for example, converting it into a standard JSON string with keys in alphabetical order) and then applying the SHA-256 hash algorithm. For example, a 64-bit hexadecimal string is obtained as a checksum. This checksum is used to quickly verify whether the data packet itself has been modified without authorization after data transmission or storage. This complete main structure of the data packet contains all necessary data, metadata, signature, and verification information, and constitutes the final signed logistics data packet.

[0064] The steps to obtain the VDF operation verification value are:

[0065] Retrieve the field mapping structure in the signed logistics data packet, parse the field where the logistics information chameleon hash sequence is located field by field, convert the field value into hash format encoded text, verify the integrity of the encoding format, extract the logistics information chameleon hash sequence as the logistics information hash value, and obtain the logistics information hash value;

[0066] Based on the logistics information hash value, it is loaded as an input into the verifiable delay function, the execution context environment is configured and the forced delay parameters are set. The number of iterative calculations, the minimum clock interval and the execution duration are set. The verifiable delay function operation is started and the verifiable delay function execution control object is generated.

[0067] Based on the verifiable delay function execution control object, iterative one-way mapping operations are continuously performed until the preset time interval is reached and the operation is completed. The final value of the hash sequence stored in the computing node is extracted as the verification identifier to generate the VDF operation verification value.

[0068] Specifically, after calling the signed logistics data packet generated by the above steps, the system first locates and accesses the specific field in the data packet used to store the "logistics information chameleon hash sequence". This field is named "logistics_chameleon_hash_sequence_payload" in the data packet structure, for example. Its content is a previously constructed JSON object, which contains the initial chameleon hash digest value and related metadata. The system then specifically parses and extracts the field value named "initial_chameleon_hash_digest" from this JSON object. This value is the hexadecimal string output by the chameleon hash function calculated previously, such as a string with a length of 128 hexadecimal characters (corresponding to a 512-bit hash value). Subsequently, the system converts and verifies the extracted hexadecimal string, that is, the value of "initial_chameleon_hash_digest", to ensure that it is a pure hash format encoded text. The conversion process mainly unifies it into a hexadecimal form represented by lowercase letters. For example, if The extracted value is "A1B2C3D4...", which is uniformly converted to "a1b2c3d4...". The subsequent encoding format integrity check includes two aspects: first, checking whether the text string consists of only valid hexadecimal characters (i.e., "0" to "9" and "a" to "f"), for example, matching through the regular expression "^[0-9a-f]+$", and second, checking whether its length meets the system preset Chameleon hash value length. For example, if the system configured Chameleon hash algorithm output is 512 bits, the hexadecimal encoded text length checked here must be 128 characters. This preset length is determined during system initialization based on the security parameters of the selected Chameleon hash algorithm. If the verification finds that the characters are illegal or the length does not match, for example, the length is 127 characters or contains non-hexadecimal characters such as "g", an error is recorded and the process is terminated. Only after the verification passes, this purified and verified hexadecimal string of "initial_chameleon_hash_digest" is officially designated as the input required for the subsequent verifiable delay function operation, that is, as the logistics information hash value, thereby obtaining the logistics information hash value.

[0069] Based on the logistics information hash value obtained in the previous link, that is, the verified hexadecimal-encoded chameleon hash digest, the system loads it as the core input item into the operation process of the verifiable delay function (VDF). In terms of specific implementation, the verifiable delay function adopts a construction based on repeated squares, for example. Its public parameters include a large modulus N (for example, a 2048-bit RSA modulus, which is generated by securely selecting two large prime numbers p and q, calculating N=pq, and destroying the knowledge of p and q. This N value is uniformly configured at the system level and shared by all VDF operations) and the logistics information hash value as input (first it needs to pass a certain mapping function, such as directly converting its hexadecimal value into a large integer, and then taking the modulus of N to obtain the value in the VDF). Next, the system configures the execution context of the VDF, which includes specifying the hardware resources used for the operation and setting the mandatory delay parameter, also known as the time parameter T. It directly determines the number of iterations of the VDF. The setting of T is based on the ratio of the target actual delay time to the single iteration operation time on the benchmark hardware. For example, if the target delay is 30 seconds and the average time to perform a modular square operation on the standard test hardware (such as a specific model of CPU core) is 3 microseconds (3×10 -6 seconds), then T is set to 30 / (3×10 -6 ) = 10,000,000 iterations. This number of iterative calculations T is a key system configuration value used to ensure the required time delay. In addition, the system also sets a minimum clock interval and an execution duration. The minimum clock interval may refer to the minimum scheduling unit or internal checkpoint interval of the VDF operation, and the execution duration is the target actual delay time set above (30 seconds). These parameters together define the intensity and expected time consumption of the VDF operation. After all configurations are completed, the system officially starts the VDF operation, creates an internal management structure containing all operation status information (such as input x, modulus N, time parameter T, start time, current iteration round, etc.), and generates a VDF execution control object.

[0070] Based on the verifiable delay function execution control object generated in the previous step, which already contains all the parameters required for the VDF operation, such as the input value x, the modulus N, and the number of iterations T, the system begins to perform the core iterative one-way mapping operation. Specifically, it performs continuous modular square operations, that is, starting from the initial value x0=x, and repeatedly calculating A total of T such iterations are performed. After each squaring, the modulus N is taken to ensure that the result remains within a specific range. This iterative process is designed to be unable to be significantly accelerated by parallel computing, thereby ensuring time consumption. The operation will continue until all T iterations are completed. The actual time spent on this process should theoretically be close to the previously set "preset time interval" (for example, 30 seconds). The preset time interval is estimated based on the number of iterations T and the benchmark time of a single iteration. When all T iterations are completed, the operation ends, and the system then extracts the final calculation result from the computing resources that perform the VDF operation. This result is the final value of the iterative sequence. This final value y exists in the form of a large integer, which is usually converted into a hexadecimal string representation. It will be used as a key verification identifier in the subsequent process. (mod N), where y is the output of the VDF, i.e., the final value of the hash sequence; x is the VDF input derived from the hash value of the logistics information; N is the large modulus used in the VDF operation; and T is the preset number of iterative calculations. The extracted final value of the hash sequence y is the generated VDF operation verification value.

[0071] The steps to obtain the blockchain anchor record with time sequence are:

[0072] Read the chameleon hash value content in the hash field area of ​​the signed logistics data packet, and call the VDF operation verification value. Put the chameleon hash value in the first position and the VDF operation verification value in the last position in the field order to build a joint structure, merge them to generate the complete combined input content, and generate the combined value of the VDF operation verification value and the chameleon hash value;

[0073] Based on the combined value of the VDF operation verification value and the chameleon hash value, the combined value is imported and a consistent hash operation is performed. The hash summary is calculated as the verification fingerprint, and then compared with the initial field structure to verify the content consistency. The result summary of the hash operation and the combined value body are recorded as the data pair to be uploaded to the chain, and the hash verification result and the data pair to be uploaded to the chain are generated;

[0074] Based on the hash check result and the data pair to be uploaded to the chain, the hash check result in the data pair is used as the check field, and the combined value is used as the anchor content field. It is written into the content area of ​​the current block and the generation timestamp, identity code and block index number are attached. The writing process is completed through node consensus to generate a blockchain anchor record with time sequence.

[0075] Specifically, the system first accurately reads the specific "hash field area" in the data structure of the signed logistics data packet generated in the previous step, such as the "initial_chameleon_hash_digest" field stored in a JSON object named "logistics_chameleon_hash_sequence_payload". The value of this field is the chameleon hash value content calculated previously, which is usually expressed as a string of hexadecimal-encoded text, such as "a1b2c3d4e5f6..." At the same time, the system retrieves the VDF operation verification value from the operation result of the Verifiable Delay Function (VDF). This verification value is The final output y calculated by the VDF is usually expressed as a hexadecimal encoded text, such as "f9e8d7c6b5a4...". After obtaining these two core values, the system strictly constructs a union structure according to the preset field order. This order stipulates that the "Chameleon hash value content" must be placed in the first position and the "VDF operation verification value" must be placed in the last position. This union structure can be a JSON object containing two key-value pairs, specifically in the form of {"ch_val": "Chameleon hash value content", "vdf_proof_val": "VDF operation verification value"}, for example {"ch_val": "a1b2c3d4e5f6...", "vdf_proof_val":

[0076] "f9e8d7c6b5a4..."}, then, in order to generate a single, unified input source, the system performs canonical serialization on this constructed union structure, for example, converting it into a compact, alphabetically keyed JSON string, such as "{\"ch_val\":\"a1b2c3d4e5f6...\",\"vdf_proof_val\":

[0077] \"f9e8d7c6b5a4...\"}", this serialized string is the complete combined input content generated by the merger, and this complete combined input content is the combined value of the VDF operation verification value and the chameleon hash value.

[0078] Based on the "combined value of the VDF operation verification value and the chameleon hash value" generated in the previous step, that is, the standardized JSON string, the system imports it into the hash operation process as input data and selects a deterministic consistent hash algorithm, such as the SHA-256 algorithm, to perform hash calculation on this combined value string. The SHA-256 algorithm is selected for its wide cryptographic security recognition and fixed 256-bit (usually expressed as 64 hexadecimal characters) output length. Its selection is determined during the system design phase based on security requirements and industry standards. The hash summary obtained after the operation, such as "

[0079] 123abc456def..." is used as a verification fingerprint. Before recording, the system will perform an internal consistency check to confirm the consistency between the "combined value" used to generate the verification fingerprint and its original components (that is, the chameleon hash value content read from the signed logistics data packet and the retrieved VDF operation verification value). Specifically, the system temporarily saves the original chameleon hash value content and VDF operation verification value, and then re-executes the process of building a joint structure from these two original values ​​and serializing it into a string, and performs an accurate byte-level comparison between the newly generated string and the "combined value" string previously used for hash calculation. If the two are completely consistent, it means that the entire process from data extraction to serialization into the string to be hashed is correct, and the content consistency verification is passed. If they are inconsistent, an internal error warning will be triggered, indicating that the data may have been damaged or unexpectedly changed during processing. After this verification is passed, the system will record and manage the SHA-256 hash digest (i.e., verification fingerprint) obtained by the consistent hashing operation and the "combined value" entity (i.e., the normalized JSON string itself) as its input source as a data pair. This data pair contains the core content anchored on the blockchain and its corresponding checksum, thereby generating a hash verification result and a data pair to be uploaded to the chain.

[0080] Based on the hash verification result (i.e., the SHA-256 verification fingerprint) generated in the previous step and the data pair to be uploaded (including the verification fingerprint and the composite value ontology), the system proceeds to construct a blockchain transaction. In the data payload of this transaction, the hash verification result of the data pair to be uploaded (for example, the SHA-256 hash value "123abc456def...") is explicitly assigned to a verification field named "verification_checksum", and the composite value ontology (i.e., the normalized JSON string "{\"ch_val\": \"...\", \"vdf_proof_val\": \"...\"}") is assigned to an anchored content field named "anchored_content_payload". In addition to these two core data fields, the system also appends other necessary auxiliary information to the transaction or its metadata, including a UTC timestamp accurate to milliseconds generated by the submitting node, such as "2025-05-09T16:05:30.123Z", which is used to mark the time when this anchoring operation occurred, and an identity code representing the system entity or node that performs this on-chain operation, such as "

[0081] LOGISTICS_ANCHOR_NODE_001", this identity code is preset in the system configuration file and is used to trace the source of the operation, as well as an internally generated unique request sequence number or task identifier, such as a UUID string, which serves as a temporary substitute or association key for the block index number. After the actual block is confirmed, the identifier will be associated with the actual block number and transaction hash. After the transaction is constructed, it is broadcast to the designated blockchain network through the node's blockchain interface. Other nodes in the network verify, sort, and package the transaction into a new block based on the established consensus mechanism (for example, if it is a consortium chain, consensus algorithms such as Raft or IBFT may be used, the choice of which depends on the specific implementation and business needs of the blockchain platform). Once the transaction is included in the consensus block and successfully uploaded to the chain, it forms an immutable blockchain anchor record with authoritative chronological order.

[0082] The steps to obtain the logistics event dependency graph are as follows:

[0083] Parse the event timestamp, location code, and event type fields in the logistics event description information node, convert them into a unified standard structure format, extract the corresponding fields in the previous event node, combine the maximum time span, maximum location code difference, and event type identification value range defined in the data dictionary, form a standardized processing basic set, and generate a field mapping set;

[0084] Based on the field mapping set, dimensionless normalization is performed on the time difference, location code difference, and event type difference. The maximum normalization factor is used to normalize the three types of differences and calculate the fusion fitness of the logistics event node. The calculation formula is:

[0085]

[0086] Among them, k is the fusion fitness of the k-th logistics event description information node, t k is the current node timestamp, is the average timestamp of the preceding nodes, Set the maximum time difference normalization value for the system, d k Code the current node location, is the average value of the location code of the previous node, Set the maximum location code difference normalization value for the system, θ k is the current node event type value, is the average value of the event type of the previous node, is the maximum difference range of event types, μ is an empirical constant used to limit the lower limit of the overall normalization;

[0087] Based on the fusion fitness, all the preceding event nodes that make the fusion fitness less than the maximum allowable fitness threshold set by the system are judged as dependent valid nodes, and a directed graph link relationship is established between the logistics event description information node and the preceding event node, and the corresponding fusion fitness is written in the edge weight field to complete the structure binding and node linking, and generate a logistics event dependency graph.

[0088] Specifically, after the system receives and parses the logistics event description information node, it extracts the original event timestamp recorded in the node, such as "2:30:15 PM CST on May 9, 2025", the original location code, and the original event type, such as "the cargo has been unloaded". After that, the system first converts these original field information into a predefined standard structure format. Specifically, the event timestamp is converted into a UNIX timestamp (the number of seconds since January 1, 1970 00:00:00 UTC), such as "1746765015", and the location code is obtained by consulting the internally maintained geocoding data. The database or location master data table converts the text description into a standardized internal location ID of a number or alphanumeric combination, such as "PVG_CARGOT2_A05". The database has pre-entered the detailed codes of all operating locations. The event type "Cargo unloaded" is queried based on the system's built-in event dictionary to obtain the corresponding digital identification code, such as "1003". The dictionary maps various logistics event descriptions to unique digital codes. At the same time, the system will retrieve all possible predecessor event nodes based on the current logistics event description information node (for example, associated with a specific waybill number). For each retrieved predecessor event node, For event nodes, the system also extracts the standardized event timestamp, location code, and event type fields. Next, the system retrieves the preset normalization parameters from the internally configured data dictionary, including the defined maximum time span, for example, set to the past 72 hours (i.e., 72×3600=259200 seconds). This value is based on the statistical analysis of the intervals between related events in historical logistics data, and is set to the maximum interval that can cover more than 95% of normal related events. It also includes the maximum location code difference. If the location code is mapped to a coordinate system or an ordered digital sequence that can calculate distances, such as the national service points The combination of administrative division and distance center point is coded as a value from 1 to 10,000. The maximum location code difference may be set to 10,000. This value represents the maximum possible location change range that the system believes in a direct logistics link, as well as the event type identification value range. If the event type is coded as an integer from 1 to 50, the maximum difference range is 49 (i.e., 50-1). These parameters obtained from the data dictionary and the standardized fields of the current node and each previous node together constitute the standardized processing basic set required for subsequent differentiation calculation and fitness analysis. Each record in the set contains the standardized t k ,d k ,θ k and the normalized t of a previous event j ,d j ,θ j , and the corresponding value, and finally generate a field mapping set.

[0089] formula: The benefit of the formula lies in that it objectively evaluates the degree of association or "fit" between a new logistics event (current node k) and one or a group of potential previous logistics events (represented by subscript j) through a standardized multi-dimensional difference quantification method. The design idea of ​​this formula is to unify the three core dimensions that affect the continuity of logistics events, namely time, location and event type, under a comprehensive indicator. Its core is to combine the differences of different properties and dimensions (time difference, location difference, event type difference) through their respective maximum possible variation ranges (Δ max The series parameters) are normalized so that they can be squared and operated at the same scale. This processing method is similar to calculating the Euclidean distance in a three-dimensional space, where each dimension represents the normalized difference of a logistics feature. The square operation amplifies the impact of large differences, while the square root operation restores the result to a similar magnitude to that of a single normalized difference term, making the fusion fitness Ψ k The interpretation of is more intuitive. Taking the absolute value of the event type difference ensures that the difference is measured in magnitude rather than direction. The introduction of the empirical constant μ, on the one hand, avoids the subsequent calculation problems (such as division by zero error or meaningless logarithm operation) that may be caused by the fusion fitness being zero in the extreme ideal case where all difference terms are zero (i.e., the current event is completely consistent with the previous event). On the other hand, it also sets a small basic "dissimilarity" lower limit for the fitness, so that even highly similar events maintain a non-zero distinction.

[0090] t k The parameter acquisition step is to represent the event timestamp of the current k-th logistics event description information node, which is directly extracted from the currently processed logistics event data and converted into a standard numerical format. For example, an event occurs at 10:30:00 on May 9, 2025 Beijing time. The system will query the record time field of the node. If the record is "2025-05-0910:30:00+08:00", it will be converted to UTC time "2025-05-0902:30:00Z", and then converted to UNIX timestamp. After consulting the Gregorian calendar and UNIX timestamp conversion rules, the corresponding number of seconds is calculated to be 1746738600. Therefore, t k =1746738600 seconds;

[0091] The parameter acquisition step is to represent the event timestamp of a previous event node to be compared with it, and the acquisition method is the same as t kSimilarly, the data of the specified preceding logistics event node j is extracted and converted into the same standard numerical format (UNIX timestamp seconds). For example, the occurrence time of the preceding event node j is recorded as "2025-05-09 09:00:00+08:00", which is converted to UTC time as "2025-05-09 01:00:00Z". The corresponding UNIX timestamp seconds are 1746733200. Therefore, in this example,

[0092] The parameter acquisition step is to represent the maximum time difference value set by the system for normalizing time differences. This parameter is not directly obtained from a single event data, but is stored in the data dictionary as a system-level configuration. Its value is set based on a statistical analysis of the time intervals between adjacent related events under normal circumstances in a large amount of historical logistics data, and a reasonable upper limit determined in combination with business experience. For example, analyzing the time difference between two consecutive events of "departure" and "arrival at the transfer station" executed by the same means of transport in the past year, it was found that 95% of the sample time differences were less than 48 hours. Taking into account some abnormal situations, the maximum time difference normalization value is set to 72 hours. In seconds, that is, 72 hours × 3600 seconds / hour = 259200 seconds. Therefore,

[0093] d k The parameter acquisition step is to obtain the numerical representation of the location code representing the current k-th logistics event description information node. The original location information is a text description. The system converts the address into longitude and latitude coordinates through the internally maintained location code conversion service, and then generates a numerical code based on these coordinates or predefined regional IDs (for example, the country is divided into several grids, and each grid is assigned a unique ID). For example, after conversion, the current address is mapped to the value 5001, which represents a specific calibration in the system location space. Therefore, d k =5001;

[0094] The parameter acquisition step is to obtain the numerical representation of the location code of the previous event node j for comparison. The acquisition method is the same as d k Similarly, the original location information of the previous node j is mapped to the corresponding value through the location code conversion service, for example, it is mapped to 4850. Therefore, in this example,

[0095] The parameter acquisition step is to represent the maximum location code difference value set by the system for normalizing location code difference, and Similarly, it is also a system-level configuration parameter, which is set according to the specific method of site coding. If the site coding is an ordered number based on the geographic area ID, for example, from 1 to 10000, then It can be set to the maximum difference in this range, that is, 10000-1=9999, or if the location code represents a certain distance unit (for example, the number of kilometers from a central point), then It will be set according to the maximum geographical scope of the business coverage. For example, if the maximum straight-line distance of a single-segment transport in the logistics process handled by the system generally does not exceed 1000, and the location code is related to this distance, then Set to 1000. In this example, if the valid range of the location code after digitization is between 1 and 8000, the system will set

[0096] θ k The parameter acquisition step is to obtain the numerical representation of the event type of the current k-th logistics event description information node. The original event type is text, such as "signed for". The system converts it into a numerical value by consulting a predefined event type dictionary (the dictionary maps all possible event text descriptions to a unique integer ID). For example, the ID corresponding to "signed for" in the dictionary is 25. This dictionary is sorted and solidified according to business needs during system design. Therefore, θ k =25;

[0097] The parameter acquisition step is to obtain the numerical representation of the event type of the preceding event node j compared with it, and the acquisition method is the same as θ k Similarly, the event type dictionary is consulted to convert the original event type text of the preceding node j (such as "in transit") into the corresponding numerical ID. For example, the ID corresponding to "in transit" is 18. Therefore, in this example,

[0098] The parameter acquisition step is to represent the maximum possible difference range after the event type is digitized. This parameter is also a system configuration. Its setting is based on the allocation range of the event type numerical ID. If the event type ID defined in the system is numbered continuously from 1 to N type ,but Usually set to N type -1, for example, if the system defines 30 different logistics event types, with IDs ranging from 1 to 30, then This parameter ensures that event type differences are properly scaled during normalization, so

[0099] The μ parameter is obtained as follows: it represents an empirical constant used to make a slight positive adjustment to the fusion fitness result. Its value is usually a positive decimal close to 0. It is determined by evaluating and tuning the model performance (for example, the accuracy and recall of dependency building) under different μ values ​​on the test dataset. The goal is to choose a value that can avoid Ψ k The value of μ is zero without excessively affecting the discrimination between event pairs. For example, after extensive historical data backtesting and parameter sensitivity analysis, it was found that when μ = 0.005, the logistics event dependency graph constructed by the system achieves a good balance between accuracy and robustness. Therefore, μ = 0.005 is set.

[0100] Calculation process: Substitute the parameter values ​​obtained above into the formula;

[0101] Calculate the time difference:

[0102]

[0103] Calculate the location code difference:

[0104]

[0105] Calculate the event type difference:

[0106]

[0107] Square the terms and sum them:

[0108] (0.020833) 2 +(0.018877) 2 +(0.241379) 2 ;

[0109] ≈0.000434+0.000356+0.058264;

[0110] ≈0.059054;

[0111] Take the square root and add the empirical constant μ:

[0112]

[0113] Ψ k ≈0.243010+0.005;

[0114] Ψ k ≈0.248010;

[0115] The results show that the fusion adaptation degree Ψ between the current logistics event description information node k and the previous event node j kThe calculated value is 0.248010, which is a dimensionless relative measure that reflects the comprehensive difference between the two in terms of time, place, and event type. The smaller the value, the stronger the correlation between the current event and the previous event, or the more "compatible" the two are in the logistics process.

[0116] Based on the fusion fitness between each current logistics event description information node k and each potential previous event node j calculated in the previous step k,j The system then compares this fusion fitness with a key system parameter, the "maximum allowable fitness threshold". This threshold, for example, is set to 0.45. It is determined during the system implementation phase by analyzing the distribution of fusion fitness of a large number of logistics event pairs with and without known associations, and using statistical methods (such as constructing receiver operating characteristic curves, or ROC curves) to find the best distinction point. The goal is to maximize the correct identification of associated events (true positives) while minimizing the probability of misidentifying unrelated events as associated (false positives). The specific judgment process is as follows: for each calculated fusion fitness Ψ k,j , if its value is strictly less than the set maximum allowable fitness threshold of 0.45 (for example, if the calculated value is 0.248010, then the condition 0.248010<0.45 holds true), the system determines that there is a valid dependency relationship between the previous event node j and the current logistics event description information node k, that is, j is a "dependent valid node" of k. On the contrary, if the fusion fitness is greater than or equal to 0.45, it is considered that the two are not sufficiently correlated and do not constitute a direct dependency. For all previous events that are determined to be dependent valid nodes, the system will use the current logistics event description information node k as the target node and the dependent valid previous event node j as the source node in the internal graph data structure to establish a directed graph link relationship (i.e., a directed edge) from j to k. This directed edge represents the order and dependency sequence of logistics events in the logical or physical process, and the system will add an attribute field of the newly created edge, such as a value named "edge_weight" or "

[0117] The "fusion_adaptability_score" field is used to accurately write the fusion adaptability value Ψ calculated between the two k,j (For example, 0.248010). This weight value can be used in subsequent more complex graph analysis algorithms, such as path optimization or anomaly detection. By repeating this judgment and linking process for all current event nodes and all their potential predecessor nodes, the structure binding and node linking are completed one by one, and finally a complete and dynamic logistics event dependency graph is constructed and updated.

[0118] The steps to obtain the verified update information certificate are:

[0119] Parse the logistics event dependency graph, verify the validity and permission level of the trapdoor key parameters submitted by the authorized holder, extract the original logistics information chameleon hash sequence from the signed logistics data packet, and form the hash benchmark for the data to be updated;

[0120] Based on the hash benchmark of the data to be updated, the trapdoor key parameters and the new logistics information are combined to construct a hash input field. The inverse operation of the trapdoor mapping is performed on the hash benchmark of the data to be updated, so that the constructed hash input field is recalculated and a new logistics information chameleon hash sequence consistent with the hash benchmark of the data to be updated is generated, thereby generating a new chameleon hash input;

[0121] Based on the new chameleon hash input, the private key of the authorized holder is loaded, the new logistics information and the new chameleon hash input are digitally signed, encapsulated into a structured data credential unit, and the signature generation timestamp and the identity of the authorized holder are written to obtain a verified updated information credential.

[0122] Specifically, the system first parses the logistics event dependency graph constructed in the previous step. The parsing process may involve locating the target event node and its associated original data record pointer in the graph based on specific query conditions (for example, the waybill number or batch number related to a logistics record to be updated). Once the relevant graph node is located, the system will clarify the specific original logistics information record that will be affected by the update operation based on the node information. Subsequently, the system strictly verifies the validity of the trapdoor key parameters submitted by the authorized holder (for example, a senior administrator with the ID "LogisticsManager_003" who has passed the system identity authentication) for updating specific logistics information. These trapdoor key parameters, such as the original random number r for a specific chameleon hash algorithm, old and secret parameter sk trapdoor, its validity verification first includes format verification, that is, checking whether the parameters conform to the expected encoding and data type, for example, whether the random number is a hexadecimal string of the specified length, and whether the secret parameter is in a legal key format. Secondly, the system will use an internal verification mechanism to compare the submitted trapdoor key parameter summary or identifier with the key information stored in the system and associated with the original hash process of the data to be updated to confirm the ownership and correctness of the key parameters. Then, the system verifies the permission level of the authorized holder "LogisticsManager_003" according to the system's built-in access control policy (this policy is pre-configured by the system security administrator based on organizational responsibilities and data sensitivity. For example, it is defined that the "LogisticsManager" role has the "Tr apdoorUpdate" permission) to confirm whether it has the right to use the trapdoor key to perform update operations on such logistics information. If the key parameters are invalid or the permissions are insufficient, the process will be terminated and the security event will be recorded. After verification, the system will extract the field content named "logistics_chameleon_hash_sequence_payload" from the historically retained "signed logistics data packet" corresponding to the information to be updated. This field completely saves the original logistics information chameleon hash sequence, including the original key logistics information items and the initial chameleon hash digest value generated at that time. This extracted complete original logistics information chameleon hash sequence object, especially the initial chameleon hash digest value and original message content contained therein, will serve as the reference benchmark for this information update operation and form the hash benchmark for the data to be updated.

[0123] Based on the hash benchmark of the data to be updated formed in the previous link, the benchmark is essentially the original logistics information chameleon hash sequence, which contains the original message M old and the corresponding original Chameleon hash value H old , and for generating H old The original random number r old (This random number may be submitted by the authorized holder as part of the trapdoor key parameters or recovered from secure storage), the system combines the valid trapdoor key parameters submitted by the authorized holder (for example, the secret value sk specific to the Chameleon hash scheme used) trapdoor ) and the "new logistics information" that needs to be updated provided by the user new (For example, the original transport status is "in transit", and the new information is updated to "delivered, consignee Zhang San"), and jointly construct the subsequent operation conditions for generating new chameleon hash random numbers. The core step is to perform the "trapdoor mapping inverse operation", that is, to use the characteristics of chameleon hash to keep the hash value unchanged for the new message M newCalculate a new random number r new , so that the public parameter pk is used to (M new ,r new ) The calculated Chameleon hash value H new Still equal to the original hash value H old The specific operation depends on the Chameleon hash algorithm used. For example, if the hash is based on the discrete logarithm H = g m h r (modp), where (modp), then the equation is m old +sk trapdoor ·r old ≡m new +sk trapdoor ·r new (modq), (where q is the order of g), from which we can solve This calculation process requires a trapdoor sk trapdoor To be executed effectively, the system performs this operation to obtain a new random number r new , then, this new random number r new With the new logistics information M new Combine and use the original public parameter pk to recalculate the chameleon hash value and verify that the result is indeed consistent with the hash benchmark H of the data to be updated. old Exactly the same, this verified, contains new logistics information M new and the newly calculated random number r new (But its hash result is still H old ) constitutes a new "logistics information chameleon hash sequence" object, and this new object is the generated new chameleon hash input.

[0124] Based on the "new chameleon hash input" generated in the previous step, the input is actually an updated "logistics information chameleon hash sequence" object, which encapsulates the new logistics information content (for example, the updated cargo status, consignee information) and the specific new random number calculated for this new content that can reproduce the original chameleon hash value. The system then loads the personal digital signature private key of the authorized holder (for example, the user ID is "LogisticsManager_003"). This private key is usually stored in a hardware security module (HSM) or a password-protected key store. The loading process may require the authorized holder to provide authentication credentials again, such as entering a PIN code or performing biometric recognition to activate the use of the private key. After the private key is successfully loaded, the system prepares the data to be signed, that is, normalizes the "new chameleon hash input" (that is, the updated entire "logistics information chameleon hash sequence" object), for example, converting it into a deterministic byte string representation (such as the UTF obtained by key sorting and compact printing of the JSON structure). -8 byte stream), then the system calls a standard digital signature algorithm, such as the Elliptic Curve Digital Signature Algorithm with the SHA-256 hash algorithm (ECDSAP-256), to sign this normalized byte stream using the authorized holder's private key, generating a digital signature value (typically consisting of two components: r and s). After signing, the system encapsulates this newly generated digital signature value, the original "new Chameleon Hash Input" object, and the signature algorithm identifier (such as "ECDSA-SHA256-P256") into a structured data credential unit. The data credential unit also contains the precise UTC timestamp generated by the signing operation (for example, "2025-05-09T17:35:10.Z") and the unique identifier of the authorized holder performing the operation (for example, "LogisticsManager_003" or its associated certificate subject name). This complete encapsulation of all the update information, the new signature, and related metadata is the final verified update information credential.

[0125] The steps to obtain the tamper-proof logistics information traceability path are:

[0126] Extract the target hash summary field, submission timestamp field, and key usage record from the verified update information certificate, locate the target node corresponding to the certificate, and pull the blockchain anchor sequence of the target node in the logistics event dependency graph. At the same time, extract the block index call frequency in the last 30 days from the call chain access log to generate the target node data audit reference set;

[0127] Based on the target node data audit reference set, the composite audit index is calculated using the following formula:

[0128]

[0129] Among them, c is the composite audit index of the cth logistics traceability chain, H c is the target node and the certificate hash matching ratio (decimal between 0-1), P c is the number of complete anchor chain blocks where the node is located, Δ s is the maximum index span difference (a dimensionless integer after normalization), τ c F is the difference in seconds between the time the voucher was submitted and the time the original record was taken. c is the number of visits to the node within 30 days, and κ is an empirical constant to prevent division by zero;

[0130] Based on the composite audit index, if the composite audit index is lower than the set maximum allowable value, the current voucher content will be written into the target node's attached record field, and the node will be synchronized to the latest index position, all reference paths and audit status will be updated, a closed-loop verification chain will be built, and a tamper-proof logistics information traceability path will be generated.

[0131] Specifically, the system first extracts three key information fields from the "verified update information certificate" generated in the previous step: the first is the "target hash summary field", whose content is the original chameleon hash value that should remain unchanged, such as "ch_val_abc123xyz789" (a schematic hash string); the second is the "submission timestamp field", which records the exact time when the "verified update information certificate" was created and submitted, such as "2025-05-09T10:30:00Z"; the third is the "key usage record", which may contain the relevant identification of the trapdoor key used for this update or a reference to the usage log, such as the record number "KUR_LogMgr003_20250509_001". Based on the extracted "target hash summary field", the system stores the data in the "logistics event dependency graph". , in order to accurately locate the original logistics event node that fully matches this hash summary. This graph is a graph-structured database that contains all logistics events and their interdependencies. The query operation, for example, achieves fast search by indexing the "original_chameleon_hash" field in the node attributes. Once the target node corresponding to the credential is successfully located (for example, the node ID "EventNode_XYZ789"), the system then pulls its complete "blockchain anchor sequence" from the associated data of the target node. The sequence is a list containing records of all the times the node (or its key information) has been anchored to the blockchain. Each record includes at least the block number, transaction hash, and the timestamp of the block, for example [{'block_number': 12345, 'tx_hash':

[0132] '0xabcdef...', 'timestamp': '2025-01-15T10:00:00Z'}, {'block_number': 12600,

[0133] 'tx_hash': '0x123456...', 'timestamp': '2025-01-20T11:00:00Z'}], at the same time, the system calls the internal "chain access log" query service, which records the history of blockchain data reading operations. The system specifically extracts the total frequency of calls (i.e., queries or accesses) of all block indexes involved in the target node's "blockchain anchor sequence" (such as 12345, 12600 mentioned above) in the last 30 days. The 30 days here is a system configuration parameter used to define the "recent" time window. For example, if the log shows that block 12345 was accessed 5 times and block 12600 was accessed 10 times, the total call frequency is 15 times. All of this extracted and queried information, including the fields in the credential, the target node's blockchain anchor sequence, and the block index call frequency, are aggregated to form the target node data audit reference set.

[0134] formula: The formula is useful in that it provides a quantitative, multi-dimensional composite audit index for evaluating the credibility or potential risk of data update behavior in a specific logistics traceability chain. The design idea of ​​the index is to integrate multiple indicators reflecting data consistency, timeliness, historical stability and attention. Specifically, the first part of the formula is Focus on how well the hash in the updated credential matches the original hash of the target node, ideally H c =1, any deviation will increase the exponential value, and the number of blocks P of the anchor chain c Adjustments are made to imply that deviations from historically consistent data are of greater concern. The second part of the formula Combined with the timeliness of the update (τ c Relative to Δ s ) and the level of attention paid to the data (F c , the more visits, the smaller the contribution, which means that the contribution of the updated audit index under high attention is relatively low);

[0135] H cThe parameter is obtained by comparing the (chameleon) hash value recorded in the "Verified Update Information Voucher" with the (chameleon) hash value of the target node in the "Target Node Data Audit Reference Set". Due to the characteristics of the chameleon hash, the hash value itself remains unchanged after the trapdoor is used to update the information. Therefore, in an ideal case, the two hash values ​​should be completely consistent. If there is an inconsistency (possibly due to data corruption, incorrect operation or other abnormalities), the matching rate will be lower than 1. The calculation method is: H c =Similarity(hash credential ,hash target_node ), where the Similarity function returns 1 for identical hashes and returns a value between 0 and 1 for partial matches or mismatches based on the similarity algorithm. In this system design, since the chameleon hash value is expected to remain unchanged, the match is binary: if the hash is completely consistent, then H c =1.0, if not consistent, then H c Set to a low penalty value representing a serious mismatch, such as 0.1, or directly judge it as an error. In this example, it is assumed that the update process is executed correctly and the hash value matches perfectly. Therefore, H c =1.0;

[0136] P c The parameter is obtained by the steps of: representing the number of blocks contained in the complete anchor chain formed on the blockchain during the entire life cycle of the target node data. This information is extracted from the "blockchain anchor sequence" of the target node in the "target node data audit reference set" and is obtained by counting the number of independent and valid anchor records in the sequence. Each anchor record corresponds to a data storage on a specific block. For example, if the "blockchain anchor sequence" of the target node contains 5 different block anchor information, then P c =5;

[0137] Δ s The parameter is obtained by taking a reference benchmark of the maximum index span difference preset by the system to measure the time span. This is a dimensionless integer after normalization. It is not directly calculated from the current transaction data, but exists as a system configuration parameter. Its value is set with reference to the average block time of the blockchain network and the typical time period of data update or version iteration in the business scenario. For example, if a "significant" time span is considered to correspond to the generation of about 10,000 blocks (about 1.7 days at a block speed of 15 seconds), in this example, Δ s =10000;

[0138] τ cThe parameter is obtained by taking the difference between the submission timestamp of the “verified updated information credential” and the first creation timestamp of the original record of the target node. Both timestamps are obtained from the “target node data audit reference set”: the “credential submission timestamp” comes directly from the credential, and the “original record time” is the initial creation time recorded in the metadata of the target node or the time when it was first anchored on the blockchain. For example, if the original record time of the target node is 12:00:00 UTC on March 1, 2025, and the credential submission time is 15:30:00 UTC on March 10, 2025, the difference between the two is 9 days, 3 hours and 30 minutes. Therefore, τ c =790200 seconds;

[0139] F c The parameter is obtained by calculating the total number of times the blockchain information associated with the target node has been accessed (called or queried) by the system or user in the last 30 days. This data is obtained from the "Block Index Call Frequency" provided in the "Target Node Data Audit Reference Set". For example, by counting the chain access logs in the past 30 days, it is found that the blockchain anchor record related to the target node has been queried a total of 24 times, then F c =24;

[0140] The steps for obtaining the κ parameter are as follows: κ represents an empirical constant to prevent division by zero errors in calculations. After system stability testing and general practice, κ is set to 1;

[0141] Calculation process: Substitute the parameter values ​​obtained above into the formula;

[0142] Calculate the square of the first part (the hash matching effect):

[0143]

[0144] Calculate the time correlation factor for the second part:

[0145]

[0146] Calculate the visit frequency correlation factor for the second part:

[0147]

[0148] Compute the product of the two factors of the second part:

[0149]

[0150] Add the square of the first part and the product of the second part, then take the square root:

[0151]

[0152]

[0153] Ξ c ≈3.97522575;

[0154] The results show that for the current update of the logistics traceability chain of Article c, its composite audit index Ξ c The calculated value is 3.97522575. This value combines multiple dimensions, such as the hash consistency of the data update (a perfect match in this case, with a contribution of 0), the relative delay time of the update, and the popularity of recent data access. It is used to quantify the overall auditability or potential risk of this data update operation.

[0155] Based on the composite audit index Ξ calculated accurately in the previous step c For example, its value is 3.97522575. The system then compares it with a "maximum allowable value" pre-set in the system configuration. This "maximum allowable value", for example, set to 15.0, is a baseline determined by the system administrator or risk control department based on a comprehensive assessment of historical data audit results, acceptable risk levels, and the sensitivity of business scenarios. Its setting logic is: by analyzing a large number of data update cases and their corresponding composite audit indexes, a critical point that can effectively distinguish between regular, reliable updates and abnormal, high-risk updates is identified. The purpose of setting this threshold is to ensure that data updates are considered to meet system security and reliability requirements only when the audit risk assessment result is lower than this standard. If the calculated composite audit index Ξ c(3.97522575) is indeed lower than the maximum allowable value (15.0) of this setting, that is, the condition 3.97522575<15.0 is established, then the system determines that this data update has passed the automatic audit check, and then the system writes the entire content of the "verified update information credential" or its core summary information into the subsidiary record field of the target node corresponding to the update in the "Logistics Event Dependency Graph", such as a list field named "update_credentials_history", and appends this credential as a new historical record. At the same time, the status of the target node in the graph may be updated, such as its data version number is increased, and the last modification time is updated to the submission time of the credential, and the system will execute The system will perform necessary index synchronization operations to ensure that any query on the node can reflect the latest information and status (i.e. "synchronize the node to the latest index position"). Furthermore, the system will check and update the associated information or dependency paths of all other event nodes that directly or indirectly reference the target node in the "Logistics Event Dependency Graph" to ensure the consistency and validity of the entire graph data. At the same time, it will update the overall audit status identification of the target node and its related traceability path, such as marking it as "audited and updated". Through this series of operations, the original records, update vouchers, audit results and blockchain anchor information are closely linked to build a complete and verifiable closed-loop verification chain, thereby generating a more complete tamper-proof logistics information traceability path that includes this update.

Claims

1. A blockchain-based logistics information tamper-proof system, characterized by: The system comprises: The logistics information initial encryption module collects key logistics information items, calls the chameleon hash function to perform hash operations on the collected key logistics information items, and obtains a logistics information chameleon hash sequence. The warehouse manager or carrier driver uses the private key to digitally sign the key logistics information items and the logistics information chameleon hash sequence to generate a signed logistics data packet; The timestamp trusted anchor module extracts the logistics information hash value from the signed logistics data packet as the input for the verifiable delay function operation, obtains the VDF operation verification value, combines the VDF operation verification value with the chameleon hash value in the signed logistics data packet, performs a hash check on the combination result, and submits the check result and the combination value together to the blockchain for recording, thereby obtaining a blockchain anchor record with a time sequence; The voucher event verification module, based on the logistics event description information submitted by the participating entities, constructs the logistics event description information into a new node of a directed acyclic graph, obtains the authenticated event node data, and links the authenticated event node data to the directed acyclic graph to form a logistics event dependency graph; The information update traceability verification module is based on the compliance update of the logistics information in the logistics event dependency graph. The authorized holder submits the corresponding trapdoor key parameters, combines the trapdoor key parameters with the new logistics information to jointly calculate and generate a new chameleon hash input, obtains the verified updated information certificate, executes the data audit process, associates the verified updated information certificate with the target node in the logistics event dependency graph, and establishes a tamper-proof logistics information traceability path.

2. The blockchain-based logistics information tamper-proof system according to claim 1 is characterized in that: The steps for obtaining the logistics information chameleon hash sequence are: Collect the cargo batch number, shipping order number, and operation time, and write the three field values ​​into the structured data input form. Then verify the alphanumeric format of the cargo batch number, the fixed prefix rule of the shipping order number, and the UTC timestamp of the operation time. If all verification results pass, write the three fields into the logistics information field mapping structure as sequential key-value pairs to generate structured key logistics information items. Based on the structured key logistics information item, the field values ​​of the cargo batch number, transport order number, and operation time are spliced ​​according to the format to construct an ASCII encoded string, which is imported as an input item into the Chameleon Hash function for processing. The structured key pair of the Chameleon Hash function is called to initialize the internal state parameters and then perform a one-way hash mapping process to output a hash digest sequence of constant length to generate an initial Chameleon Hash digest value; The initial chameleon hash summary value is field-coupled with the structured key logistics information item to construct a data structure with a signature preprocessing identifier. The chameleon hash summary value is embedded in the hash field area of ​​the structure, and additional fields are written to describe the source module, timestamp number and summary generation batch number. This serves as a reproducible traceability infrastructure to generate a logistics information chameleon hash sequence.

3. The blockchain-based logistics information tamper-proof system according to claim 1 is characterized in that: The steps for obtaining the signed logistics data packet are: Call the private key information corresponding to the warehouse manager or carrier driver to complete the permission verification and key activation of the current operator's identity, write the key binding information and the corresponding identity code into the digital signature preparation structure, and generate the signature execution preparation item; Based on the signature execution preparation item, the structured key logistics information item and the logistics information chameleon hash sequence are field-concatenated in a preset data order, and a unified message body is constructed as the input source data to be signed. The private key is loaded, and the elliptic curve encryption signature is executed on the input source data to obtain a digital signature object with an encrypted signature field; Based on the digital signature object, the signature field, the original structured key logistics information item, the logistics information chameleon hash sequence and the signature executor identity are uniformly encapsulated into the data packet main structure, and the operation timestamp and data integrity check field are configured to generate a signed logistics data packet.

4. The blockchain-based logistics information tamper-proof system according to claim 1 is characterized in that: The steps for obtaining the VDF operation verification value are as follows: Retrieve the field mapping structure in the signed logistics data packet, parse the field where the logistics information chameleon hash sequence is located field by field, convert the field value into hash format encoded text, verify the integrity of the encoding format, extract the logistics information chameleon hash sequence as the logistics information hash value, and obtain the logistics information hash value; Based on the logistics information hash value, it is loaded as an input into the verifiable delay function, the execution context environment is configured and the forced delay parameters are set, the number of iterative calculations, the minimum clock interval and the execution duration are set, the verifiable delay function operation is started, and the verifiable delay function execution control object is generated; Based on the verifiable delay function execution control object, the iterative one-way mapping operation is continuously performed until the preset time interval is reached and the operation is completed, the final value of the hash sequence stored in the computing node is extracted as the verification identifier, and the VDF operation verification value is generated.

5. The blockchain-based logistics information tamper-proof system according to claim 1 is characterized in that: The steps for obtaining the time-series blockchain anchor record are as follows: Read the chameleon hash value content in the hash field area of ​​the signed logistics data packet, and call the VDF operation verification value, put the chameleon hash value in the first position and the VDF operation verification value in the last position in the field order to construct a joint structure, merge them to generate a complete combined input content, and generate a combined value of the VDF operation verification value and the chameleon hash value; Based on the combined value of the VDF operation verification value and the chameleon hash value, the combined value is imported and a consistent hash operation is performed. The hash digest is calculated as the verification fingerprint, and then compared with the initial field structure to verify the consistency of the content. The result digest of the hash operation and the combined value body are recorded as the data pair to be uploaded to the chain, and the hash verification result and the data pair to be uploaded to the chain are generated; Based on the hash verification result and the data pair to be uploaded to the chain, the hash verification result in the data pair is used as the verification field and the combined value is used as the anchor content field and written into the content area of ​​the current block, and the generation timestamp, identity code and block index number are attached. The writing process is completed through node consensus to generate a blockchain anchor record with time sequence.

6. The blockchain-based logistics information tamper-proof system according to claim 1 is characterized in that: The steps for obtaining the logistics event dependency graph are as follows: Parse the event timestamp, location code, and event type fields in the logistics event description information node, convert them into a unified standard structure format, extract the corresponding fields in the previous event node, combine the maximum time span, maximum location code difference, and event type identification value range defined in the data dictionary, form a standardized processing basic set, and generate a field mapping set; Based on the field mapping set, dimensionless normalization is performed on the time difference, location code difference and event type difference respectively, and the maximum normalization factor is used for normalization. The three types of differences are normalized and the fusion fitness of the logistics event node is calculated; Based on the fusion fitness, all preceding event nodes that make the fusion fitness less than the maximum allowable fitness threshold set by the system are determined to be dependent valid nodes, a directed graph link relationship is established between the logistics event description information node and the preceding event node, and the corresponding fusion fitness is written in the edge weight field to complete the structure binding and node linking, and generate a logistics event dependency graph.

7. The blockchain-based logistics information tamper-proof system according to claim 1 is characterized in that: The steps for obtaining the verified update information certificate are: Parse the logistics event dependency graph, verify the validity and permission level of the trapdoor key parameters submitted by the authorized holder, extract the original logistics information chameleon hash sequence from the signed logistics data packet, and form the hash benchmark of the data to be updated; Based on the hash benchmark of the data to be updated, a hash input field is constructed in combination with the trapdoor key parameter and the new logistics information, and the inverse operation of the trapdoor mapping is performed on the hash benchmark of the data to be updated, so that the constructed hash input field is recalculated and a new logistics information chameleon hash sequence consistent with the hash benchmark of the data to be updated is generated, thereby generating a new chameleon hash input; Based on the new chameleon hash input, the identity private key of the authorized holder is loaded, the new logistics information and the new chameleon hash input are digitally signed, encapsulated into a structured data certificate unit, and the signature generation timestamp and the identity of the authorized holder are written to obtain a verified updated information certificate.

8. The blockchain-based logistics information tamper-proof system according to claim 1 is characterized in that: The steps for obtaining the tamper-proof logistics information traceability path are: Extract the target hash summary field, submission timestamp field, and key usage record from the verified update information voucher, locate the target node corresponding to the voucher, and pull the blockchain anchor sequence of the target node in the logistics event dependency graph. At the same time, extract the block index call frequency in the last 30 days from the call chain access log to generate a target node data audit reference set; Calculating a composite audit index based on the target node data audit reference set; Based on the composite audit index, if the composite audit index is lower than the set maximum allowable value, the current voucher content will be written into the target node's attached record field, and the node will be synchronized to the latest index position, all reference paths and audit status will be updated, a closed-loop verification chain will be constructed, and a tamper-proof logistics information traceability path will be generated.

Images