A logistics information anti-tampering system based on a blockchain

Abstract

The application relates to the technical field of logistics information tamper-proofing, in particular to a logistics information tamper-proofing system based on a block chain, which comprises a logistics information initial encryption module, acquires key logistics information items, calls a chameleon hash function to perform hash operation on the acquired key logistics information items, obtains a logistics information chameleon hash sequence, and uses a private key of a warehouse manager or a driver to perform digital signature on the key logistics information items and the logistics information chameleon hash sequence to generate a signed logistics data packet. In the application, the key logistics information items are acquired, and the chameleon hash function is used to perform hash operation on the logistics information, so that the tamper-proofing capability of the information itself in the transmission process is enhanced; meanwhile, the private key is used for digital signature binding operation of the operator identity, identity traceability of the information source is realized, and identity forgery or impersonation is effectively prevented.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of logistics information tamper-proofing technology, and particularly relates to a logistics information tamper-proofing system based on a block chain. BACKGROUND

[0002] The field of logistics information tamper-proofing technology is a key information technology field focusing on the security and trusted management of logistics supply chain data, covering security protection mechanisms for each link of logistics information collection, storage, transmission, verification, updating and auditing, and taking cryptography technology, digital signature technology, trusted timestamp technology and distributed ledger technology as core support to form a series of technical systems that guarantee that logistics data cannot be tampered with by unauthorized parties, are easy to trace and verify, and have transparent credibility.

[0003] In the prior art, the time sequence consistency and identity binding mechanism of logistics information are not deeply guaranteed, which may cause poor timeliness of logistics information and easy tampering or forgery of data record time sequence in actual operation; for example, when a logistics event is disputed, since the delay mechanism of information record is not strictly limited, it may cause disagreement on the time of event occurrence among the parties involved, making it difficult to determine the responsibility of the logistics link, and affecting the effective solution of logistics disputes; at the same time, the correlation between logistics events in the prior art is weak, and no clear logical dependency structure is formed, resulting in poor timeliness of logistics event auditing and tracing, and unclear dependency relationship of related events, making it difficult to quickly and efficiently trace and trace when abnormal events or illegal behaviors occur. Therefore, improvement is needed. SUMMARY

[0004] The purpose of the present application is to solve the problems in the prior art and provide a logistics information tamper-proofing system based on a block chain.

[0005] In order to achieve the above-mentioned purpose, the present application adopts the following technical scheme: a logistics information tamper-proofing system based on a block chain comprises:

[0006] A logistics information initial encryption module collects key logistics information items, calls a chameleon hash function to perform hash operation on the collected key logistics information items to obtain a logistics information chameleon hash sequence, and a warehouse manager or a driver uses a 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 anchoring module extracts the logistics information hash value as an input item of a verifiable delay function operation based on the signed logistics data packet, obtains a VDF operation verification value, combines the VDF operation verification value with the chameleon hash value in the signed logistics data packet, performs hash check on the combination result, and submits the check result to the blockchain together with the combination value for recording to obtain a blockchain anchoring record containing a time sequence;

[0008] The credentialized event verification module constructs logistics event description information submitted by a participating entity as a new node of a directed acyclic graph, obtains authenticated event node data, links the authenticated event node data to the directed acyclic graph, and forms a logistics event dependency graph.

[0009] The information update traceable check module authorizes a holder to submit a corresponding trapdoor key parameter based on a compliance update of logistics information in the logistics event dependency graph, jointly calculates a new chameleon hash input based on the trapdoor key parameter and new logistics information, obtains verified update information credentials, performs a data audit process, associates the verified update information credentials to a target node in the logistics event dependency graph, and establishes a tamper-proof logistics information traceability path.

[0010] Preferably, the logistics information chameleon hash sequence acquisition step is:

[0011] The cargo batch number, the transport number, and the operation time are collected, and the three field values are written into a structured data input form respectively. The alphanumeric mixed arrangement format of the cargo batch number, the fixed prefix rule of the transport number, and the legality of the UTC timestamp of the operation time are sequentially verified. If the verification result is passed, the three fields are written into a logistics information field mapping structure in the order of key-value pairs to generate a structured key logistics information item.

[0012] Based on the structured key logistics information item, the field values of the cargo batch number, the transport number, and the operation time are spliced according to the format to construct an ASCII encoded string as an input item imported into the chameleon hash function for execution processing. After the structured key pair of the chameleon hash function initializes the internal state parameters, a one-way hash mapping process is performed to output a hash digest sequence of constant length to generate an initial chameleon hash digest value.

[0013] The initial chameleon hash digest value is coupled with the structured key logistics information item to construct a data structure with a signed preprocessing identifier. The chameleon hash digest value is embedded into the hash field area in the structure, and the additional field description source module, timestamp number, and digest generation batch number are written to serve as a reproducible traceability basic structure to generate a logistics information chameleon hash sequence.

[0014] Preferably, the obtaining step of the signed logistics data packet is:

[0015] The corresponding private key information of the warehouse manager or the delivery driver is called to complete the permission verification and key activation of the current operator identity, the key binding information is written into the digital signature preparation structure together with the corresponding identity code, and a signature execution preparation item is generated;

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

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

[0018] Preferably, the obtaining step of the VDF operation verification value is:

[0019] The field mapping structure in the signed logistics data packet is called, the field where the logistics information chameleon hash sequence is located is parsed field by field, the field value is converted into a hash format coded text, and the integrity of the coding format is verified, the logistics information chameleon hash sequence is extracted as a logistics information hash value, and the logistics information hash value is obtained;

[0020] Based on the logistics information hash value, as an input item, load into the verifiable delay function, configure the execution context environment and set the forced delay parameter, set the iteration calculation times, the minimum clock interval and the execution duration, start the verifiable delay function operation, and generate a verifiable delay function execution control object;

[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 hash sequence final value stored in the calculation node is extracted as a verification identifier, and a VDF operation verification value is generated.

[0022] Preferably, the obtaining step of the time sequence containing the blockchain anchor record is:

[0023] The chameleon hash value content in the hash field area of the signed logistics data packet is read, and the VDF operation verification value is called, the chameleon hash value is placed in the front position and the VDF operation verification value is placed in the rear position to construct a joint structure, and a complete combined input content is generated, and a combined value of the VDF operation verification value and the chameleon hash value is generated;

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

[0025] Based on the hash check result and the pair of data to be chained, the hash check result in the data pair is written as a check field, and the combination value is written as an anchor content field in the content area of the current block and is attached with a generation timestamp, an identity code and a block index number. The writing process is completed through node consensus to generate a time sequence containing a block chain anchor record.

[0026] Preferably, the acquisition step of the logistics event dependency graph is:

[0027] The event timestamp, location code and event type field in the logistics event description information node are parsed and uniformly converted into a standard structure format, and the corresponding fields in the previous event node are extracted. Combined with the maximum time span, the maximum location code difference and the event type identification value domain defined in the data dictionary, a standardized processing basic set is formed, and a field mapping set is generated;

[0028] Based on the field mapping set, dimensionless normalization processing is performed on the time difference, location code difference and event type difference, and the maximum normalization factor standardization is used to normalize the three types of difference values and calculate the fusion adaptation degree of the logistics event node;

[0029] Based on the fusion adaptation degree, all previous event nodes with a fusion adaptation degree less than the maximum allowable adaptation threshold set by the system are determined as dependent valid nodes. The logistics event description information node and the previous event node are linked to form a directed graph link relationship, and the corresponding fusion adaptation degree is written in the edge weight field. The structure binding and node linking are completed, and the logistics event dependency graph is generated.

[0030] Preferably, the acquisition step of the verified update information voucher is:

[0031] The logistics event dependency graph is parsed, the effectiveness and authority level of the trap key parameter submitted by the authorized holder are verified, and the original logistics information chameleon hash sequence is extracted from the signed logistics data packet to form a to-be-updated data hash reference;

[0032] Based on the to-be-updated data hash reference, the trap key parameter and the new logistics information are combined to construct a hash input field, and the trap mapping inverse operation is performed on the to-be-updated data hash reference. The hash input field constructed after the operation generates a new logistics information chameleon hash sequence consistent with the to-be-updated data hash reference, and a new chameleon hash input is generated.

[0033] Based on the new chameleon hash input, load the identity private key of the authorized holder, digitally sign the new logistics information and the new chameleon hash input, encapsulate it into a structured data certificate unit, and write in the signature generation timestamp, the identity of the authorized holder, to obtain the verified update information certificate.

[0034] Preferably, the acquisition step of the tamper-proof logistics information traceability path is:

[0035] Extract the target hash digest field, submission timestamp field and key usage record in the verified update information certificate, locate the target node corresponding to the certificate, pull the blockchain anchor sequence of the target node in the logistics event dependency graph, and simultaneously call the chain access log to extract the block index calling frequency in the recent 30 days to generate the target node data audit reference set;

[0036] Based on the target node data audit reference set, a composite audit index is calculated;

[0037] Based on the composite audit index, if the composite audit index is lower than the set maximum allowable value, the current certificate content is written into the target node attached record field, and the node is synchronized to the latest index bit, the update of all reference paths and audit state is updated, the closed loop verification chain is constructed, and the tamper-proof logistics information traceability path is generated.

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

[0039] In the present application, by collecting key logistics information items and using chameleon hash function to perform hash operation on the logistics information, the tamper resistance of the information itself in the transmission process is enhanced; at the same time, the private key is used for digital signature binding operation person identity, realizing the identity traceability of information source, effectively preventing identity forgery or impersonation; in the data recording stage, a verifiable delay function is introduced to calculate the logistics information hash value, so as to forcibly set the delay to guarantee the timing accuracy and unforgeability of information recording, thereby improving the consistency of logistics recording and actual business process; at the same time, the event description information is used to construct a directed acyclic graph node structure, and an explicit dependency relationship between nodes is established, so as to improve the logical transparency and audit convenience between logistics events; in addition, by introducing a trap key parameter and combining the characteristics of the chameleon hash function, information compliance update is realized without destroying the original hash consistency, which not only guarantees the safe and compliant update of information, but also ensures the traceability of information; then the data audit association verifies the updated information, forms the logistics information traceability path, strengthens the transparency and traceability efficiency of the whole system, reduces the tampering risk, and effectively meets the high requirements of logistics business safety management and judicial audit. BRIEF DESCRIPTION OF DRAWINGS

[0040] Figure 1A system flowchart of the present application. DETAILED DESCRIPTION

[0041] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application is further described in detail below in combination with the drawings and examples. It should be understood that the specific examples described herein are only used to explain the present application and do not limit the present application.

[0042] Please refer to Figure 1 The present application provides a technical solution: a logistics information tamper-proofing system based on a blockchain includes:

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

[0044] A timestamp trusted anchor module, based on the signed logistics data packet, extracts a logistics information hash value as an input item of a verifiable delay function operation, obtains a 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 to the blockchain together with the combined value for recording to obtain a blockchain anchor record containing a time sequence.

[0045] A credentialized event verification module, based on logistics event description information submitted by a participating entity, constructs the logistics event description information as a new node of a directed acyclic graph, obtains authenticated event node data, links the authenticated event node data to the directed acyclic graph, and forms a logistics event dependency graph.

[0046] An information update traceable check module, based on a compliance update of logistics information in the logistics event dependency graph, authorizes a holder to submit a corresponding trapdoor key parameter, jointly calculates a new chameleon hash input with the trapdoor key parameter and new logistics information, obtains verified update information credentials, executes a data audit process, associates the verified update information credentials to a target node in the logistics event dependency graph, and establishes a tamper-proof logistics information traceability path.

[0047] The acquisition steps of the logistics information chameleon hash sequence are:

[0048] Collect the goods batch number, transport number and operation time, write the three field values into the structured data input form respectively, check the alphanumeric mixed arrangement format of the goods batch number, the fixed prefix rule of the transport number and the legality of the UTC timestamp of the operation time in turn, if the verification results all pass, write the three fields in the order of key-value pairs into the logistics information field mapping structure, generate structured key logistics information items;

[0049] Based on the structured key logistics information item, the field values of the goods batch number, the transport number and the operation time are spliced according to the format to construct an ASCII encoded string as an input item imported into the chameleon hash function for execution processing, and after calling the structured key of the chameleon hash function to initialize the internal state parameters, the one-way hash mapping process is executed, and the hash digest sequence with constant length is output, generating the initial chameleon hash digest value;

[0050] Couple the initial chameleon hash digest value with the structured key logistics information item, build a data structure with signed preprocessing identifier, embed the chameleon hash digest value into the hash field area in the structure, and write the additional field description source module, timestamp number and digest generation batch number, as a reproducible traceability basic structure, generate the 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 internally predefined structured data input form object, which temporarily stores these data for subsequent verification. Next, the system initiates a strict verification process for each data item in the specified order. First, for the cargo batch number, the system verifies its format according to a regular expression, such as "[A-Z]{2}\d{8}[A-Z]{3}$". This 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 compliant 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 note the failure reason as "cargo batch number format inconsistency". Subsequently, the transport order number is verified, with the fixed prefix rule set to start with "YSD-" and be followed by exactly 10 digits. This rule, such as "YSD-", is configured during system initialization and originates from logistics business specifications or partner agreements. For example, a compliant transport order number is "YSD-0123456789". The system judges by checking the prefix of the string and the length and character type of the subsequent digit part. Any inconsistency will result in a verification failure and record the reason as "transport order number prefix or length inconsistency". Finally, the verification of the operation time focuses on whether it conforms to the legality of the international standard UTC timestamp. The specific format requirement is ISO8601 extended format, which is "YYYY-MM-DDTHH:MM:SS.sssZ", for example "2025-05-09T15:30:00.The system calls the built-in date and time parsing library ("123Z") to attempt to convert the input operation time string strictly according to this format. It also checks if the converted time is a valid past or present time; for example, the time cannot be later than the current system time plus a small tolerance (e.g., 5 seconds, to handle possible minor synchronization delays). If parsing fails or the timestamp is too early, the system records the verification failure and the reason, such as "incorrect operation time format" or "invalid operation timestamp." Only when all three key pieces of information—the goods batch number, the shipping document number, and the operation time—successfully pass their respective verification logic will the system continue execution and record this information. The three validated field values, in a fixed order of "cargo batch number," "transport document number," and "operation time," are written as key-value pairs into a newly created logistics information field mapping structure instance. For example, the key could be "cargo_batch_identifier," with the value being the validated cargo batch number string; the key could be "transport_document_id," with the value being the validated transport document number string; and the key could be "timestamp_of_operation," with the value being the validated and normalized operation time string. After this structure is instantiated, structured key logistics information items are generated.

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

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

[0054] SH12345678BJG|YSD-0123456789|20250509153000Z”, then this concatenated string is constructed into an ASCII encoded byte sequence as the core input message item into the chameleon hash function processing flow, 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 the public parameters and the user's specific public key and the corresponding trapdoor (part of the private key), the public parameters such as a large prime P (for example, a 2048-bit prime number, which is selected based on the current recommended cryptography security standard), a large prime factor Q of P-1, and a cyclic group generator G of order Q, the user's public key contains Y = G X (mod P), 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 comparable to the bit length of Q, after the initialization is completed, the system performs the one-way hash mapping process, combines the ASCII encoded string (as the message M) and the random number R, and calculates the hash value through the chameleon hash algorithm, the calculation process can be represented as: where h is the calculated initial chameleon hash digest value, M is the ASCII encoded string to be hashed, R is the random number generated for this operation, G, Y and P are the public parameters and part of the user's public key of the chameleon hash function, || represents the byte string concatenation operation, and H0 is a standard cryptography hash function, such as SHA-256, whose output is used as an exponent, and the operation result h is a hash digest sequence with 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 represented as 512 hexadecimal characters, this output sequence is the generated initial chameleon hash digest value.

[0055] After the initial chameleon hash digest value generated in the previous step is logically field-coupled with the structured key logistics information item generated in the first step, the system begins to build a data structure with a signature preprocessing identifier, which is a fixed string constant, such as "LOGIS_CH_PREPROC_V1.0", whose value is defined at system deployment, used to indicate the type and version of this data structure. In the process of building this data structure, the system will define a series of explicit fields for it, one of which is a key field, such as "chameleon_digest_field", which is specifically used to embed the initial chameleon hash digest value calculated by the chameleon hash function (i.e. h in the previous step, stored in hexadecimal string form). In addition to the hash value itself, the system also writes several additional descriptive and tracking fields into the data structure, including the source module identifier, whose value is selected from a pre-set module code list, such as "WM_INPUT_SYS_002", which contains all possible system module codes that can generate such data. The specific code value is automatically filled based on the system component where the current operation occurs. The pre-set list is set in reference to the division and coding specification of each functional module during system design. It also includes a timestamp number, which is a sequence number generated to ensure the uniqueness of the record, for example, the number may be based on the current date and a daily self-incrementing counter, such as "2025050910350000001", where "202505091035" represents the year, month, day, and time, followed by a 7-digit self-incrementing sequence. The generation rule is to read the current maximum sequence value and add one each time the digest is created, which ensures that the digests generated within the same minute also have unique numbers. A digest generation batch number is also written, such as "BATCH_MAY092025_005", which is used to group the digests 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 contains a batch sequence number within the day. These additional fields, together with the embedded chameleon hash digest value and the coupled structured key logistics information item (which itself contains the cargo batch number, transport number, and operation time), form a complete data entity that can serve as the basis for subsequent reproducible traceability processes. The final data structure, such as a JSON object containing all the above fields, is identified as a logistics information chameleon hash sequence.

[0056] The signed logistics data packet acquisition step is:

[0057] The private key information of the warehouse manager or the driver is called to complete the permission verification and key activation of the current operator's identity, and the key binding information is written into the digital signature preparation structure together with the corresponding identity code to generate a 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 field concatenated according to a preset data sequence, and a unified message body is constructed and merged as a to-be-signed input source data, a private key is loaded, elliptic curve encryption signature is performed on the input source data, and a digital signature object with an encrypted signature field is obtained;

[0059] 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 a data packet main structure body, an operation timestamp and a data integrity verification field are configured, and a signed logistics data packet is generated.

[0060] Specifically, after calling the private key information corresponding to the warehouse manager or the delivery driver, the system first identifies the identity code of the current operator according to the current operation session or the work voucher (for example, employee number or login token) provided by the operator, for example, "the identity code of driver Zhang San is SJ00768", then the system performs a strict permission verification process, compares the identity code with the preset access control list (ACL) or role library, the ACL is configured by the authorized administrator during the system deployment stage, which defines in detail the operation set allowed to be performed by each identity code or role, for example, the ACL may contain the entry "identity code: SJ00768, allowed operation: [generate logistics signature, query transportation task]", if the operation requested by the current request (i.e. generating a digital signature) exists in the allowed operation list of the identity code, and the operator account state is normal (for example, not disabled or marked as suspicious), the permission verification is passed, if not, the operation is immediately terminated and the permission exception event is recorded, after the permission verification is successful, the key activation stage is entered, the system will prompt the operator to input the activation password of his private key, for example, a complex password with a length of at least 8 characters containing uppercase and lowercase letters, numbers and special symbols, or through the connected hardware security module (such as USBKey or smart card) to request biometric verification (such as fingerprint), the success of this activation password or biometric verification will be used to decrypt the user private key stored in the secure medium, which is always encrypted in a static state, for example, encrypted using AES-256 algorithm, the number of activation attempts will be limited, for example, if the wrong password is entered for 3 times in succession, the key usage permission of the account will be temporarily locked for 30 minutes, this threshold (3 attempts) and lock duration (30 minutes) are set according to the security policy, which considers the security requirements of preventing brute force cracking and the convenience of user operation, 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, i.e. the digital signature preparation structure, this structure will also record the permission verification result as "pass" and the key activation status as "success", this digital signature preparation structure constitutes the signature execution preparation item.

[0061] After the operator's authority and the key are activated, the system performs the preparation item based on the signature generated in the previous step, and then acquires 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 these two data structures according to a predetermined data sequence, for example, the sequence of the serialized string of the "structured key logistics information item" 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 standardized JSON format, i.e., the keys are sorted alphabetically and there is no unnecessary white space, to ensure that the generated data to be signed is completely consistent each time. In this way, a unified byte stream message body is constructed, which is the input source data to be signed. Then, the system securely loads the activated operator private key from the signature execution preparation item, which is protected by a security mechanism in memory. Then, the system performs an elliptic curve digital signature operation on the unified message body, for example, the SM2 elliptic curve algorithm recommended by the National Cryptography Administration, or the widely used ECDSA P-256 curve with SHA-256 hashing (the selection is based on the security level determined during system design, for example, P-256 provides about 128 bits of security strength). The signature process first applies the SHA-256 hashing algorithm to the input source data to be signed (i.e., the unified message body) to generate a 256-bit hash digest H. Then, using the loaded private key d A and a cryptographically secure random number k generated specifically for this signature operation (to ensure that the k value is different each time), the hash digest H is signed. 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 (mod n), and the second component s = k -1 (H + r·d A )(mod n), where n is the order of the base point G. If r or s is 0, then 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 elliptic curve private key of the signer, and k is the random number generated for this signature operation. The signature algorithm finally outputs a digital signature field composed of two parts (usually two large integers r and s), which together with the original data to be signed form a digital signature object with an encrypted signature field.

[0062] Based on the digital signature object generated in the previous step, which already contains the specific content of the data to be signed and the corresponding r and s values ​​of the elliptic curve digital signature, the system begins to extract and integrate the core elements of the signing operation. Specifically, it extracts the digital signature field (i.e., the values ​​of r and s, usually represented as hexadecimal strings), the original structured key logistics information items obtained in the previous process (containing initial collected information such as cargo batch number, waybill number, and operation time), and the logistics information chameleon hash sequence obtained in the previous process (containing the initial chameleon hash digest value, a copy of the key logistics information item, and related metadata), along with the signature executor identity identifier obtained from the signature execution preparation item (e.g., "SJ00768"). All these information items are then uniformly encapsulated into a newly defined main data packet structure. This structure, for example, uses JSON format, and its internal fields have explicit names and orders, such as "signer_id", "...", ...

[0063] During the encapsulation process, the system also configures two additional management fields for this main data packet structure: The first is the operation timestamp, recording the precise Coordinated Universal Time (UTC) at which the current encapsulation operation was completed, such as "2025-05-09T15:45:10.550Z", using the ISO8601 standard format. The second is a data integrity verification field. The value of this field is the hash value calculated by serializing all other contents of the entire main data packet structure (before filling this verification field) (e.g., converting to a canonical JSON string with keys arranged alphabetically), 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 data packet structure, containing all necessary data, metadata, signature, and verification information, constitutes the final generated signed logistics data packet.

[0064] The steps for obtaining the VDF operation verification value are as follows:

[0065] Retrieve the field mapping structure in the signed logistics data packet, parse the field containing the logistics information chameleon hash sequence 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, as an input item loaded into a verifiable delay function, a configuration execution context environment is configured and a mandatory delay parameter is set, the number of iteration calculations, the minimum clock interval and the execution duration period are set, the verifiable delay function operation is started, and a 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 hash sequence final value stored in the calculation node is extracted as a verification identifier, and a VDF operation verification value is generated.

[0068] Specifically, after retrieving the signed logistics data package generated in the preceding step, the system first locates and accesses the specific field in the data package for storing the "logistics information chameleon hash sequence", which is named, for example, "logistics_chameleon_hash_sequence_payload" in the data package structure, and its content is a previously constructed JSON object containing 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, which is the hexadecimal string output by the previously calculated chameleon hash function, for example, a string of 128 hexadecimal characters (corresponding to a 512-bit hash value). Subsequently, the system performs format conversion and verification on the extracted hexadecimal string, i.e., the value of "initial_chameleon_hash_digest", to ensure that it is a pure hash format encoded text. The conversion process mainly converts it to lowercase hexadecimal form, for example, if the extracted value is "A1B2C3D4...", it is converted to "a1b2c3d4...". The subsequent encoding format integrity verification includes two aspects: one is to check whether the text string is composed of only valid hexadecimal characters (i.e., "0" to "9" and "a" to "f"), for example, by matching the regular expression "^[0-9a-f]+$", and the other is to verify whether its length meets the system's preset chameleon hash value length. For example, if the system configures the chameleon hash algorithm to output 512 bits, the length of the hexadecimal encoded text 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 is not consistent, for example, the length is 127 characters or contains non-hexadecimal characters such as "g", an error is recorded and the process is aborted. Only after the verification passes, the purified and verified hexadecimal string of "initial_chameleon_hash_digest" is officially designated as the input required for subsequent verifiable delay function operations, i.e., 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 step, namely the verified hexadecimal-encoded chameleon hash digest, the system loads it as a core input into the Verifiable Delay Function (VDF) operation flow. Specifically, the Verifiable Delay Function employs a construction based on, for example, repeated squares. Its common parameters include a large modulus N (e.g., a 2048-bit RSA modulus, generated by safely 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 across all VDF operations) and the logistics information hash value as input (which first needs to be converted to a large integer using a defined mapping function, such as directly converting its hexadecimal value to a large integer, and then taking the modulus with N to obtain the hash value). Next, the system configures the execution context of VDF, which includes specifying the hardware resources used for the operation and setting the forced latency parameter, also known as the time parameter T. This parameter directly determines the number of iterations of VDF. The setting of T is based on the ratio of the actual target latency to the time of a single iteration on the benchmark hardware. For example, if the target latency is 30 seconds, and the average time to perform a modulo-square operation on standard test hardware (such as a specific CPU core) is 3 microseconds (3 × 10⁻⁶), then... -6 If the time interval is 10 seconds, then T is set to 30 / (3×10). -6 = 10,000,000 iterations. This number of iterations T is a key system configuration value used to ensure the required time delay. In addition, the system also sets the minimum clock interval and execution duration. The minimum clock interval may refer to the minimum scheduling unit or internal checkpoint interval of the VDF operation, while the execution duration is the target actual delay time (30 seconds) set above. These parameters together define the intensity and expected time consumption of the VDF operation. After all configurations are completed, the system officially starts the verifiable delay function 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 the verifiable delay function execution control object.

[0070] Based on the verifiable delay function execution control object generated in the previous step, which contains all the parameters required for VDF operations, such as the input value x, the modulus N, and the number of iterations T, the system begins to execute the core iterative one-way mapping operation. Specifically, it performs continuous modulo-square operations, that is, it repeatedly calculates from the initial value x0 = x. The total number of iterations T is performed, and the modulo operation after squaring is a key step to ensure that the result remains within a certain range. This iterative process is designed to be unable to be significantly accelerated by parallel computing, ensuring that the time consumption will continue until the T iterations are completed. The actual time spent on this process should theoretically be close to the previously set "preset time interval" (e.g., 30 seconds), which is estimated based on the number of iterations T and the benchmark time consumption of a single iteration. When the T iterations are completed, the operation ends, and the system extracts the final calculation result from the computing resources that performed the VDF operation. This result is the final value of the iteration sequence This final value y exists in the form of a large integer and is usually converted into a hexadecimal string representation. It will be used as a key verification identifier in subsequent processes. (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 iterations. The extracted hash sequence final value y is the generated VDF operation verification value.

[0071] The acquisition steps of the time sequence-containing blockchain anchored record are as follows:

[0072] The chameleon hash value content in the signed logistics data packet hash field area is read, and the VDF operation verification value is called. The chameleon hash value is placed in the front position, and the VDF operation verification value is placed in the rear position to construct a joint structure. The complete combined input content is generated, and the combined value of the VDF operation verification value and the chameleon hash value is generated.

[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 digest is calculated as a verification fingerprint, and the initial field structure is compared to verify the consistency of the content. The result digest of the hash operation and the combined value body are recorded as a pair of data to be chained, generating a hash verification result and a pair of data to be chained.

[0074] Based on the hash verification result and the pair of data to be chained, the hash verification result in the data pair is written as a verification field, and the combined value is written as an anchor content field in the content area of the current block, with a timestamp, an identity code, and a block index number attached. The writing process is completed through node consensus, generating a time sequence-containing blockchain anchored record.

[0075] Specifically, the system first accurately reads the stored "initial_chameleon_hash_digest" field in the specific "hash field area" inside the data structure of the signed logistics data package generated in the previous step, such as a JSON object named "logistics_chameleon_hash_sequence_payload", the value of this field is the previously calculated chameleon hash value content, usually represented 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 VDF, also usually represented as a hexadecimal encoded text, such as "f9e8d7c6b5a4…", after obtaining these two core values, the system strictly constructs a joint structure according to the preset field order, which specifies that the "chameleon hash value content" must be placed in the front position and the "VDF operation verification value" must be placed in the rear position, this joint structure can be a JSON object containing two key-value pairs, the specific form is {"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 normalizes and serializes this constructed joint structure, for example, converts it to a compact JSON string with keys sorted in alphabetical order, specifically like "{\"ch_val\":\"a1b2c3d4e5f6…\",\"vdf_proof_val\":

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

[0078] Based on the "combined value of VDF operation verification value and chameleon hash value" generated in the previous step, which is the standardized JSON string, the system imports it as input data into the hash operation process. A deterministic consistent hashing algorithm, such as SHA-256, is selected to perform hash calculations on this combined value string. The SHA-256 algorithm is chosen due to its widespread cryptographic security acceptance and fixed 256-bit (usually represented as 64 hexadecimal characters) output length. Its selection is determined during the system design phase based on security requirements and industry standards. The resulting hash digest is, for example, "

[0079] "123abc456def..." is used as a verification fingerprint. Before recording, the system performs an internal consistency check. This check aims to confirm the consistency between the "combined value" used to generate the verification fingerprint and its original components (i.e., the chameleon hash value read from the signed logistics data packet and the retrieved VDF operation verification value). Specifically, the system temporarily saves the original chameleon hash value and VDF operation verification value, then re-executes the process of constructing a combined structure from these two original values ​​and serializing it into a string. The newly generated string is then compared precisely byte-level with the "combined value" string previously used for hash calculation. If the two are completely consistent, it indicates that the entire process from data extraction to serialization into the string to be hashed is error-free 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 corrupted or unexpectedly changed during processing. After this verification is passed, the system records and manages the SHA-256 hash digest (i.e., verification fingerprint) obtained by the aforementioned consistent hashing operation and the "combined value" ontology (i.e., the normalized JSON string itself) 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 to the blockchain (containing the verification fingerprint and the combined value ontology), the system begins to construct a blockchain transaction. In the data payload of this transaction, the hash verification result (e.g., the SHA-256 hash value "123abc456def...") in the data pair to be uploaded to the blockchain is explicitly assigned to a verification field named "verification_checksum", and the combined value ontology (i.e., the normalized JSON string "{\"ch_val\" containing the chameleon hash value and the VDF operation verification value) is also assigned. The values ​​"..." and "vdf_proof_val": "..."} are 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", to mark the time this anchoring operation occurred, and an identity code representing the system entity or node that performed this on-chain operation, such as "...

[0081] "LOGISTICS_ANCHOR_NODE_001" is a pre-defined identifier in the system configuration file used to trace the source of an operation, and also serves as an internally generated unique request sequence number or task identifier, such as a UUID string, as a temporary substitute or association key for the block index number. After the actual block is confirmed, this identifier will be associated with the real block number and transaction hash. Once 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 according to a predetermined consensus mechanism (e.g., in the case of a consortium blockchain, consensus algorithms such as Raft or IBFT may be used, the choice of which depends on the specific implementation of the blockchain platform and business requirements). Once the transaction is included in a consensus-reaching block and successfully uploaded to the chain, an immutable blockchain anchor record with an authoritative time order is formed.

[0082] The steps for obtaining the logistics event dependency graph are as follows:

[0083] The event timestamp, location code, and event type fields in the logistics event description information node are parsed, uniformly converted into a standard structure format, and the corresponding fields in the preceding event nodes are extracted. Combined with the maximum time span, maximum location code difference, and event type identifier value range defined in the data dictionary, a standardized processing base set is formed, and a field mapping set is generated.

[0084] Based on the field mapping set, dimensionless normalization is performed on the time difference, location code difference, and event type difference, respectively. Maximum normalization factor standardization is then used to normalize the three types of differences and calculate the fusion fit degree of the logistics event nodes. The calculation formula is as follows:

[0085]

[0086] Among them, Ψ k Let t be the fusion adaptation degree of the information node describing the k-th logistics event. k This is the timestamp of the current node. This is the average timestamp of the preceding nodes. Set the maximum time difference normalization value for the system, d k Encode the current node location. The average value is used to encode the location of the preceding node. To set the maximum location code difference normalization value for the system, θ k The event type value for the current node. This is the average value of the event type of the preceding node. The maximum difference range for event types is defined by μ, which is an empirical constant used to limit the lower bound of the overall normalization.

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

[0088] Specifically, upon receiving and parsing the logistic event description information node, the system extracts the original event timestamp, e.g. "2025-05-09 14:30:15 CST", the original location code, and the original event type, e.g. "cargo unloaded", from the node. Then, 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 elapsed since 00:00:00 UTC on January 1, 1970), e.g. "1746765015". The location code is converted into a standardized internal location ID, e.g. "PVG_CARGOT2_A05", by looking up an internal geographic coding database or location master data table, which pre-records detailed codes for all operating locations. The event type "cargo unloaded" is converted into a corresponding numerical identification code, e.g. "1003", according to an in-built event dictionary, which maps various logistic event descriptions to unique numerical codes. At the same time, the system retrieves all possible preceding event nodes associated with the current logistic event description information node (e.g. associated with a specific waybill number). For each retrieved preceding event node, the system extracts its already standardized event timestamp, location code, and event type fields. Next, the system retrieves preset normalization parameters from an internal data dictionary, including a defined maximum time span, e.g. set to the past 72 hours (i.e. 72 x 3600 = 259200 seconds), which is based on statistical analysis of the interval between associated events in historical logistic data, and selected to cover more than 95% of normal associated events, a maximum location code difference, which is set to 10000 if the location code is mapped to a coordinate system or an ordered numerical sequence that can calculate distance, e.g. the nationwide service points are coded as 1 to 10000 according to administrative division and distance from the center point, and an event type identification value range, which is set to 49 (i.e. 50-1) if the event type is coded as an integer from 1 to 50. These parameters obtained from the data dictionary, together with the standardized fields of the current node and each preceding node, form a standardized processing basis set required for subsequent differential calculation and adaptation analysis. Each record in the set contains the standardized t k ,d k ,θ k of the current event and the standardized t j ,d j ,θ j of a preceding event, as well as the corresponding value. Finally, a field mapping set is generated.

[0089] Formula: The formula has the benefit 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 preceding logistics events (represented by subscript j) through a standardized multi-dimensional difference quantification method. The design idea of the formula is to consider the three core dimensions of time, location, and event type that affect the continuity of logistics events under a comprehensive index. The core is to normalize the differences in different properties and dimensions (time difference, location difference, event type difference) through their respective maximum possible variation range (Δ max The series of parameters) so that they can be squared and summed under 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 influence of larger differences, and the square root operation restores the result to a similar magnitude as a single normalized difference item, making the interpretation of the fusion fit degree Ψ k more intuitive. Taking the absolute value of the event type difference ensures that the difference is measured in size rather than direction. The introduction of the empirical constant μ avoids the problem of zero fusion fit degree in the extreme ideal case where all difference items are zero (i.e., the current event is completely consistent with the preceding event), which may cause division by zero error or meaningless logarithmic operation. On the other hand, it also sets a small basic "non-similarity" lower limit for the fit degree, so that even highly similar events also maintain a non-zero distinction;

[0090] t k The parameter is the event timestamp representing the current kth logistics event description information node, which is directly extracted from the current processing logistics event data and converted to a standard numerical format. For example, an event occurred on May 9, 2025, at 10:30:00 in Beijing time. The system will query the record time field of the node, and if the record is "2025-05-09 10:30:00 +08:00", it will be converted to UTC time "2025-05-09 02:30:00Z". Then it is converted to UNIX timestamp. After consulting the Gregorian calendar and UNIX timestamp conversion rules, it is calculated that the corresponding second number is 1746738600. Therefore, t k = 1746738600 seconds;

[0091] The parameter is the event timestamp representing the current kth logistics event description information node, which is directly extracted from the current processing logistics event data and converted to a standard numerical format. For example, an event occurred on May 9, 2025, at 10:30:00 in Beijing time. The system will query the record time field of the node, and if the record is "2025-05-09 10:30:00 +08:00", it will be converted to UTC time "2025-05-09 02:30:00Z". Then it is converted to UNIX timestamp. After consulting the Gregorian calendar and UNIX timestamp conversion rules, it is calculated that the corresponding second number is 1746738600. Therefore, t kSimilarly, data from a specified preceding logistics event node j is extracted and converted to a numerical format of the same standard (UNIX timestamp in seconds). For example, if the occurrence time record of preceding event node j is "2025-05-09 09:00:00+08:00", the converted UTC time is "2025-05-09 01:00:00Z", and its corresponding UNIX timestamp in seconds is 1746733200. Therefore, in this example,

[0092] The steps for obtaining the parameter are as follows: The parameter represents the maximum time difference value set by the system for normalizing time differences. This parameter is not directly obtained from individual event data, but is stored in the data dictionary as a system-level configuration. Its value is set based on statistical analysis of the time intervals between adjacent related events under normal circumstances in a large amount of historical logistics data, combined with business experience to determine a reasonable upper limit. For example, analyzing the time difference between "departure" and "arrival at the transfer station" for the same transportation vehicle in the past year, it was found that 95% of the sample time differences were less than 48 hours. Considering some abnormal situations, the maximum time difference normalization value was set to 72 hours, which is 72 hours × 3600 seconds / hour = 259200 seconds. Therefore...

[0093] d k The parameter acquisition steps are as follows: The numerical representation of the location code of the current k-th logistics event description information node. The original location information is a text description. The system converts the address into latitude and longitude coordinates through an internally maintained location code conversion service. Then, based on these coordinates or a predefined region ID (e.g., dividing the country into several grids, each grid is assigned a unique ID), a numerical code is generated. For example, after conversion, the current address is mapped to the value 5001. This value represents a specific location within the system's location space. Therefore, d... k =5001;

[0094] The steps for obtaining the parameters are as follows: The numerical representation of the location code of the preceding event node j to be compared is obtained in the same way as d. k Similarly, the location information of the preceding node j is mapped to a corresponding numerical value through a location encoding conversion service. For example, it is mapped to 4850. Therefore, in this example,

[0095] The steps for obtaining the parameters are as follows: represents the maximum location code difference set by the system for normalizing location code differences, and... Similarly, it is also a system-level configuration parameter, and its setting depends on the specific method of location coding. If the location coding is based on ordered numbers of geographic region IDs, such as from 1 to 10000, then... This can be set to the maximum difference within this range, i.e., 10000-1 = 9999, or if the location code represents a unit of distance (e.g., kilometers from a center point). This setting will be based on the maximum geographical area covered by the business. For example, if the maximum straight-line distance for a single segment of logistics 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 effective range of the location code after numerical conversion is between 1 and 8000, then the system is set to...

[0096] θ k The parameter acquisition steps are as follows: The numerical representation of the event type for the current k-th logistics event description node is used. The original event type is text, such as "signed for." The system converts it to a numerical value by consulting a predefined event type dictionary (which maps all possible event text descriptions to unique integer IDs). For example, the ID corresponding to "signed for" in the dictionary is 25. This dictionary is compiled and fixed according to business requirements during system design. Therefore, θ k =25;

[0097] The steps for obtaining the parameters are as follows: The numerical representation of the event type of the preceding event node j being compared is obtained in the same way as θ. k Similarly, by consulting the event type dictionary, the original event type text of the preceding node j (e.g., "in transit") is converted into the corresponding numerical ID. For example, the ID corresponding to "in transit" is 18. Therefore, in this example,

[0098] The steps to obtain the parameter are as follows: This represents the maximum possible range of differences after the event type is quantified. This parameter is also a system configuration, and its setting is based on the allocation range of the event type's numerical ID. If the event type IDs defined in the system are consecutively numbered 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 differences in event types are scaled appropriately during normalization, therefore,

[0099] The step of obtaining the parameter μ is to represent an empirical constant for slightly positive adjustment of the fusion fitting degree result, the value is usually a positive small number close to 0, and the value is determined by evaluating and optimizing the model performance (for example, the accuracy and recall rate of dependency construction) under different μ values on the test data set, the goal is to select a value that can avoid Ψ k is zero, and does not excessively affect the distinction between events. For example, through a large amount of historical data backtracking test and parameter sensitivity analysis, it is found that when μ = 0.005, the logistics event dependency graph constructed by the system reaches a good balance between accuracy and robustness, so μ = 0.005 is set.

[0100] Calculation process: substitute the obtained parameter value into the formula;

[0101] Calculate the time difference term:

[0102]

[0103] Calculate the location encoding difference term:

[0104]

[0105] Calculate the event type difference term:

[0106]

[0107] Square each term and sum them up:

[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 result shows that the fusion fitting degree Ψ kThe calculated value is 0.248010. This value is a dimensionless relative measure that reflects the degree of comprehensive difference between the two in terms of time, location and event type. The smaller the value, the stronger the correlation between the current event and the preceding event, or the more "compatible" the two are in terms of logistics process.

[0116] The fusion fit degree Ψ between each current logistics event description information node k and its potential preceding event node j calculated in the previous step is based on the fusion fit degree Ψ between each current logistics event description information node k and its potential preceding event node j. k,j The system then compares this fusion fit score with a key system parameter—the "maximum permissible fit score threshold." This threshold, for example, is set to 0.45. It was determined during system implementation by analyzing the fusion fit score distribution of a large number of known correlated and uncorrelated logistics event pairs, and using statistical methods (such as constructing a receiver operating characteristic curve, i.e., a ROC curve) to find the optimal distinguishing point. The goal is to maximize the correct identification of correlated events (true positives) while minimizing the probability of incorrectly identifying uncorrelated events as correlated (false positives). Specifically, for each calculated fusion fit score Ψ... k,j If its value is strictly less than the set maximum allowable fit threshold of 0.45 (for example, if the calculated value is 0.248010, then the condition 0.248010 < 0.45 holds), the system determines that there is a valid dependency relationship between the preceding event node j and the current logistics event description information node k, that is, j is a "dependent valid node" of k. Conversely, if the fusion fit is greater than or equal to 0.45, it is considered that the two are not related enough and do not constitute a direct dependency. For all preceding events determined to be dependent valid nodes, the system will establish a directed graph link relationship (i.e., a directed edge) from j to k in the internal graph data structure, with the current logistics event description information node k as the target node and the dependent valid preceding event node j as the source node. This directed edge represents the logical or physical sequence and dependency order of logistics events. In addition, the system will add attribute fields to the newly created edge, such as "edge_weight" or "..."

[0117] The "fusion_adaptability_score" field should be precisely entered with the calculated fusion adaptability value Ψ between the two. k,j (e.g., 0.248010) This weight value can be used for more complex graph analysis algorithms, such as path optimization or anomaly detection. By repeating this determination 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 credential are as follows:

[0119] The logistics event dependency graph is parsed, the validity and authority level of the trapdoor key parameter submitted by the authorized holder are verified, the original logistics information chameleon hash sequence is extracted from the signed logistics data packet, and the to-be-updated data hash benchmark is formed;

[0120] Based on the to-be-updated data hash benchmark, the trapdoor key parameter and the new logistics information are combined to construct a hash input field, the to-be-updated data hash benchmark is subjected to trapdoor mapping inverse operation, the constructed hash input field is recalculated to generate a new logistics information chameleon hash sequence consistent with the to-be-updated data hash benchmark, and a new chameleon hash input is generated.

[0121] 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 subjected to digital signature processing, are encapsulated into a structured data certificate unit, and are written with a signature generation timestamp and an identity of the authorized holder, to obtain a verified update information certificate.

[0122] Specifically, the system first parses the logistics event dependency graph constructed in the previous step. This parsing process may involve locating a target event node and its associated original data record pointer in the graph according to specific query conditions (for example, a waybill number or batch number related to a to-be-updated logistics record). Once the relevant graph node is located, the system will determine the specific original logistics information record that will be affected by this 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 an ID of "LogisticsManager_003" who has passed system identity authentication) for updating specific logistics information. These trapdoor key parameters, such as the original random number r old and the secret parameter sk trapdoorThe effectiveness verification first includes format checking, that is, checking whether the parameters meet the expected encoding and data type, for example, whether the random number is a hexadecimal string of a specified length, and whether the secret parameter is a legal key format. Secondly, the system compares the submitted trapdoor key parameter digest or identifier with the key information stored in the system associated with the original hash process of the data to be updated to confirm the ownership and correctness of the key parameter. Thirdly, the system checks the authority level of the authorized holder "LogisticsManager_003" and confirms whether it has the right to use the trapdoor key to perform update operations on such logistics information according to the built-in access control policy of the system (which is pre-configured by the system security administrator according to organizational responsibilities and data sensitivity, for example, defining that the "LogisticsManager" role has the "TrapdoorUpdate" authority for "CriticalShipmentData"). If the key parameter is invalid or the authority is insufficient, the process will be aborted and a security event will be recorded. After verification, the system extracts the field content named "logistics_chameleon_hash_sequence_payload" from the "signed logistics data package" corresponding to the information to be updated, which completely saves the original logistics information chameleon hash sequence, including the original key logistics information item and the initial chameleon hash digest value generated at that time. The extracted complete original logistics information chameleon hash sequence object, especially the initial chameleon hash digest value and the original message content contained therein, will serve as the reference basis for this information update operation, forming the update data hash reference.

[0123] Based on the update data hash reference formed in the previous link, the reference 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 the original random number r old used to generate H old (which may be submitted by the authorized holder as part of the trapdoor key parameter or recovered from secure storage), the system combines the valid trapdoor key parameter submitted by the authorized holder (such as the secret value sk trapdoor specific to the chameleon hash scheme used) and the "new logistics information" M new provided by the user that needs to be updated (for example, the original transportation status is "in transit", and the new information is updated to "delivered, recipient Zhang San"), to jointly construct the operation condition for generating the new chameleon hash random number. The core step is to perform "trapdoor mapping inverse operation", that is, using the characteristics of chameleon hash, to keep the hash value unchanged, and to generate a new message M newCalculate a new random number r new This allows the use of public parameters pk on (M) new ,r new The calculated chameleon hash value H new It is still equal to the original hash value H. old The specific calculation 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 (mod p), then the equation is m old +sk trapdoor ·r old ≡m new +sk trapdoor ·r new (mod q), (where q is the order of g), from which we can solve for This calculation process requires the trapdoor sk. trapdoor Only then can the operation be executed effectively; the system will then perform this operation to obtain a new random number r. new Then, use this new random number r new With new logistics information M new Combine the results and recalculate the chameleon hash value using the original public parameters pk, verifying that the result does indeed match the hash benchmark H of the data to be updated. old Completely consistent, this verified information includes new logistics information M. new and the newly calculated random number r new (but its hash result is still H) old The combination of these elements forms a completely new "Logistics Information Chameleon Hash Sequence" object, which is the new chameleon hash input generated.

[0124] Based on the "new chameleon hash input" generated in the previous link, which is actually an updated "logistics information chameleon hash sequence" object, it encapsulates the new logistics information content (such as the updated cargo status, the information of the recipient) and the specific new random number calculated for this new content, which 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 "LogisticsManager_003"), which is usually stored in a hardware security module (HSM) or a password-protected key store, and may require the authorized holder to provide authentication credentials again, such as entering a PIN code or performing biometric identification, to activate the use permission of the private key. After the private key is loaded successfully, the system prepares the data to be signed, that is, it normalizes the "new chameleon hash input" (that is, the entire updated "logistics information chameleon hash sequence" object), for example, it converts it into a deterministic byte string representation (such as a UTF-8 byte stream obtained by sorting the keys and compactly printing the JSON structure), then the system calls the standard digital signature algorithm, such as the elliptic curve digital signature algorithm (ECDSA) with SHA-256 hash algorithm (ECDSA-SHA256-P256), uses the private key of the authorized holder to sign the normalized byte stream, generates a digital signature value (usually including r and s two components), after completing the signature, the system encapsulates the newly generated digital signature value, the original "new chameleon hash input" object, and the identification of the algorithm used for signature (such as "ECDSA-SHA256-P256") into a structured data certificate unit, and in the data certificate unit, the UTC timestamp generated by this signature operation (for example, "2025-05-09T17:35:10.Z") and the unique identity of the authorized holder performing this operation (for example, "LogisticsManager_003" or its associated certificate subject name) are also written accurately. The complete encapsulation body containing all updated information, new signature and related metadata is the final verified update information certificate.

[0125] The acquisition steps of the tamper-proof logistics information traceability path are:

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

[0127] Based on the target node data audit reference set, calculate the composite audit index, the calculation formula is:

[0128]

[0129] wherein Ξ c is the composite audit index of the c-th supply chain, H c is the target node's hash matching rate with the certificate (0-1 decimal), P c is the number of full anchor chain blocks that the node belongs to, Δ s is the maximum index span difference (after normalization, it is a dimensionless integer), τ c is the second-level difference between the certificate submission time and the original record time, F c is the number of visits 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 certificate content is written to the target node's attached record field, and the node is synchronized to the latest index bit, the reference path and audit status are updated, a closed-loop verification chain is constructed, and a tamper-proof supply chain information tracing path is 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 digest field", which contains 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 or usage log reference of the trapdoor key used for this update, such as record number "KUR_LogMgr003_20250509_001". Based on the extracted "target hash digest field", the system performs a query in the "supply chain event dependency graph" data storage to accurately locate the original supply chain event node that completely matches this hash digest. This graph is a graph structure database that contains all supply chain events and their mutual dependencies. The query operation is implemented by, for example, indexing the "original_chameleon_hash" field in the node attributes to achieve fast lookup. Once the target node corresponding to the certificate is successfully located (for example, node ID "EventNode_XYZ789"), the system then pulls its complete "blockchain anchor sequence" from the associated data of the target node. This sequence is a list that contains the node's (or its key information) historical records of being anchored to the blockchain, each record at least including the block number, transaction hash, and the timestamp of the block, such as [{'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 reading operations on blockchain data. The system specifically extracts the total frequency of calls (i.e., queries or accesses) of all block indices (such as 12345 and 12600 mentioned above) involved in the target node's "blockchain anchor sequence" within the last 30 days. Here, 30 days 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 this extracted and queried information, including fields in the credentials, the target node's blockchain anchor sequence, and block index call frequency, is summarized to form the target node data audit reference set.

[0134] formula: The advantage of this formula lies in providing a quantitative, multi-dimensional composite audit index to assess the credibility or potential risks of data update behavior on a specific logistics traceability chain. The index is designed to integrate multiple indicators reflecting data consistency, timeliness, historical stability, and attention. Specifically, the first part of the formula… Monitor the degree of match between the hash in the updated credential and the original hash of the target node. Ideally, H c =1, any deviation will increase the exponent value, while the number of blocks P of the anchor chain is used. c The adjustment implies that deviations in historically consistent data will receive more attention, as stated in the second part of the formula. It incorporates the timeliness of updates (τ) c Relative to Δ s ) and the level of attention given to the data (F c The more visits a page receives, the smaller the contribution of this feature, meaning that the contribution of the updated audit index is relatively low under high attention.

[0135] H cThe acquisition step of the parameter is a decimal value between 0 and 1 representing the matching rate of the target node to the credential hash, which is obtained by comparing the (chameleon) hash value recorded in the "verified update information credential" with the (chameleon) hash value of the original record of the target node in the "target node data audit reference set". Due to the characteristics of the chameleon hash, the hash value remains unchanged after using the trapdoor update information. Therefore, in an ideal case, the two hash values should be completely consistent. If there is a discrepancy (which may be due to data corruption, incorrect operation or other abnormalities), the matching rate will be less than 1. The calculation method is: H c = Similarity(hash credential , hash target_node ), where the Similarity function returns 1 for completely identical hashes and returns a value between 0 and 1 for partial matching or non-matching according to the similarity algorithm. In the system design, since the chameleon hash value is expected to remain unchanged, this matching is binary: if the hashes are completely consistent, H c = 1.0, and if they are not consistent, H c is set to a low value representing a severe mismatch, for example, 0.1, or directly determined as an error. In this example, it is determined that the update process is executed correctly and the hash values are perfectly matched, so H c = 1.0;

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

[0137] Δ s The acquisition step of the parameter is a reference benchmark for measuring the maximum index span difference of the time span, which is a normalized dimensionless integer. It is not directly calculated from the current transaction data, but exists as a system configuration parameter. Its value is set by referring to the average block generation 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 corresponds to the generation of about 10000 blocks (about 1.7 days at a block generation speed of 15 seconds), in this example, Δ s = 10000;

[0138] τ cThe acquisition step of the parameter is the difference between the submission timestamp of the "verified update information certificate" and the first creation timestamp of the target node original record, both of which are obtained from the "target node data audit reference set": the "certificate submission timestamp" is directly from the certificate, and the "original record time" is the initial creation time of the record in the target node metadata or the time when it is first anchored on the blockchain. For example, if the target node original record time is March 1, 2025 12:00:00 UTC, and the certificate submission time is March 10, 2025 15:30:00 UTC, the difference between the two is 9 days, 3 hours and 30 minutes, so c τ = 790200 seconds;

[0139] F c The acquisition step of the parameter is the total number of times the blockchain information associated with the target node is accessed (called or queried) by the system or users within the last 30 days, which is obtained from the "block index call frequency" provided by 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 anchored record related to the target node is queried a total of 24 times, so c F = 24;

[0140] The acquisition step of the κ parameter is an empirical constant to prevent division by zero errors in calculations. After system stability testing and general practice, κ = 1 is set;

[0141] Calculation process: substitute the obtained parameter values into the formula;

[0142] Square the first part (hash matching degree influence term):

[0143]

[0144] Calculate the time-related factor of the second part:

[0145]

[0146] Calculate the access frequency-related factor of the second part:

[0147]

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

[0149]

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

[0151]

[0152]

[0153] Ξ c ≈3.97522575;

[0154] The result shows that, for the current update of the c-th logistics traceability chain, the composite audit index Ξ c The calculated value is 3.97522575, which integrates the hash consistency of data update (perfect match in this case, contribution is 0), the relative delay time of update, and the accessed heat of recent data, etc. multiple dimensions to quantify the overall auditability or potential risk of this data update operation.

[0155] Based on the accurate calculation of the previous step, the composite audit index Ξ c , for example, its value is 3.97522575, the system will compare it with a "maximum allowable value" preset in the system configuration next. The "maximum allowable value", for example, is set to 15.0, which is determined by the system administrator or risk control department based on historical data audit results, acceptable risk levels, and the sensitivity of business scenarios. The setting logic is: by analyzing a large number of data update cases and their corresponding composite audit indexes, a critical point is identified that can effectively distinguish between regular and trusted updates and abnormal and high-risk updates. The purpose of setting this threshold is to ensure that only when the audit risk assessment result is below this standard, the data update is considered to meet the system security and trust requirements. If the calculated composite audit index Ξ c(3.97522575) is indeed lower than the set maximum allowable value (15.0), i.e. 3.97522575 < 15.0 holds, 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 credentials" or its core summary information into the attached record field of the target node corresponding to this update in the "logistics event dependency graph", for example, a list field named "update_credentials_history", appends this credential as a new historical record, at the same time, the state of the target node in the graph may be updated, for example, its data version number increases, the last modification time is updated to the submission time of the credential, and the system will perform necessary index synchronization operations to ensure that any query to the node can reflect the latest information and state (i.e. "synchronize the node to the latest index bit"), further, the system will check and update the association information or dependency path of all other event nodes in the "logistics event dependency graph" that directly or indirectly reference the target node, to ensure the consistency and validity of the entire graph data, and update the overall audit state identifier of the target node and its related traceability path, for example, marked as "audited update", through a series of operations, the original record, update credentials, audit results and blockchain anchor information are closely associated to build a complete and verifiable closed-loop verification chain, thereby generating a more perfect anti-tamper logistics information traceability path containing this update.

Claims

1. A blockchain-based anti-tampering system for logistics information, characterized in that, The system includes: 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 the carrier driver uses a 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 anchoring module extracts the hash value of the logistics information as the input of the verifiable delay function operation based on the signed logistics data packet to obtain the VDF operation verification value. The VDF operation verification value is combined with the chameleon hash value in the signed logistics data packet, and the combination result is hash verified. The verification result and the combination value are submitted to the blockchain for recording to obtain a blockchain anchoring record with time sequence. The credential event verification module constructs a new node in a directed acyclic graph based on the logistics event description information submitted by the participating entities, 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 performs compliant updates based on logistics information in the logistics event dependency graph. The authorized holder submits the corresponding trapdoor key parameters, and calculates a new chameleon hash input by combining the trapdoor key parameters with the new logistics information to obtain a verified update information credential. The data audit process is then executed, and the verified update information credential is associated with the target node in the logistics event dependency graph to establish a tamper-proof logistics information traceability path.

2. The blockchain-based logistics information anti-tampering system according to claim 1, characterized in that, The steps for obtaining the chameleon hash sequence of the logistics information are as follows: Collect the batch number, transit number, and operation time of the goods. Write the values ​​of the three fields into the structured data input form. Validate the alphanumeric mixed format of the batch number, the fixed prefix rule of the transit number, and the validity of the UTC timestamp of the operation time in turn. If all the validation 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 items, the field values ​​of the goods batch number, transport order number and operation time are concatenated according to the format to construct an ASCII encoded string, which is then imported into the Chameleon hash function for processing. After the structured key pair of the Chameleon hash function is called to initialize the internal state parameters, a one-way hash mapping process is executed, and a hash digest sequence of constant length is output to generate the initial Chameleon hash digest value. The initial chameleon hash digest value is coupled with the structured key logistics information items to construct a data structure with a signature preprocessing identifier. The chameleon hash digest value is embedded in the hash field area of ​​the structure, and additional fields describing the source module, timestamp number, and digest generation batch number are written in. This serves as a reproducible traceability base structure to generate a logistics information chameleon hash sequence.

3. The blockchain-based logistics information anti-tampering system according to claim 2, characterized in that, The steps for obtaining the signed logistics data packet are as follows: The system retrieves the private key information corresponding to the warehouse administrator or the carrier driver to complete the authorization verification and key activation of the current operator's identity. The key binding information and the corresponding identity code are written into the digital signature preparation structure to 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 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 cryptographic signature of the input source data is executed to obtain a digital signature object with a cryptographic signature field. Based on the digital signature object, the signature field, the original structured key logistics information items, the logistics information chameleon hash sequence, and the signature executor's identity are uniformly encapsulated into the main structure of the data packet, and the operation timestamp and data integrity verification field are configured to generate a signed logistics data packet.

4. The blockchain-based logistics information anti-tampering system according to claim 1, characterized in that, The steps for obtaining the VDF operation verification value are as follows: The field mapping structure in the signed logistics data packet is retrieved, the field containing the logistics information chameleon hash sequence is parsed field by field, the field value is converted into hash format encoded text, the integrity of the encoding format is verified, the logistics information chameleon hash sequence is extracted as the logistics information hash value, and the logistics information hash value is obtained. Based on the hash value of the logistics information, it is loaded into the verifiable delay function as an input item. The execution context environment is configured and the forced delay parameters are set. The number of iteration calculations, the minimum clock interval and the execution duration are set. The verifiable delay function operation is started and a verifiable delay function execution control object is generated. Based on the verifiable delay function execution control object, iterative one-way mapping operations are continuously performed until a 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 a verification identifier to generate a VDF operation verification value.

5. The blockchain-based logistics information anti-tampering system according to claim 1, characterized in that, The steps for obtaining the time-series blockchain anchored record are as follows: Read the chameleon hash value content of the hash field area in the signed logistics data packet, retrieve the VDF operation verification value, and construct a joint structure by placing the chameleon hash value first and the VDF operation verification value last according to the field order. Combine and generate complete combined input content to generate a combined value of VDF operation verification value and 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 a verification fingerprint, and then compared with the initial field structure to verify the consistency of the content. The hash operation result digest and the combined value body are recorded as a data pair to be uploaded to the chain, and a hash verification result and a 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. The data is written into the content area of ​​the current block and a timestamp, identity code and block index number are added. The writing process is completed through node consensus to generate a blockchain anchor record with time sequence.

6. The blockchain-based logistics information anti-tampering system according to claim 1, characterized in that, The steps for obtaining the logistics event dependency graph are as follows: The event timestamp, location code, and event type fields in the logistics event description information node are parsed, uniformly converted into a standard structure format, and the corresponding fields in the preceding event nodes are extracted. Combined with the maximum time span, maximum location code difference, and event type identifier value range defined in the data dictionary, a standardized processing base set is formed, and a field mapping set is generated. Based on the field mapping set, the time difference, location code difference and event type difference are respectively processed by dimensionless normalization, and the maximum normalization factor is used for standardization. The three types of differences are normalized and the fusion adaptation degree of logistics event nodes is calculated. Based on the fusion adaptability, all preceding event nodes whose fusion adaptability is less than the maximum allowable adaptability threshold set by the system are determined as 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 adaptability 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 anti-tampering system according to claim 1, characterized in that, The steps for obtaining the verified updated information credential are as follows: The logistics event dependency graph is analyzed to verify the validity and permission level of the trapdoor key parameters submitted by the authorized holder. The original logistics information chameleon hash sequence is extracted from the signed logistics data packet to form the hash base of the data to be updated. Based on the hash benchmark of the data to be updated, a hash input field is constructed by combining the trapdoor key parameters and the new logistics information. The trapdoor mapping reverse operation is performed on the hash benchmark of the data to be updated, so that the constructed hash input field is recalculated and generates a new logistics information chameleon hash sequence that is consistent with the hash benchmark of the data to be updated, and a new chameleon hash input is generated. Based on the new chameleon hash input, the authorized holder's private key is loaded, and 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 authorized holder's identity identifier are written in to obtain the verified updated information credential.

8. The blockchain-based logistics information anti-tampering system according to claim 1, characterized in that, The steps for obtaining the tamper-proof logistics information traceability path are as follows: Extract the target hash digest field, submission timestamp field, and key usage record from the verified updated information credential, locate the target node corresponding to the credential, and pull the blockchain anchor sequence of the target node in the logistics event dependency graph. At the same time, call the chain access log to extract the block index call frequency in the last 30 days and generate a target node data audit reference set. Calculate the 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 is written into the target node's auxiliary record field, and the node is synchronized to the latest index position. All reference paths and audit statuses are updated, a closed-loop verification chain is constructed, and a tamper-proof logistics information traceability path is generated.

Images