Blockchain-driven cross-domain archive circulation right ownership tracing method and system

Abstract

The application belongs to the technical field of blockchain and digital archive management, and discloses a blockchain-driven cross-domain archive circulation right ownership tracing method and system; a session identifier is generated at a cross-domain interface, a subject identifier, a source domain identifier, a target domain identifier, an archive identifier, an operation type, an operation time and a target entity handover element are collected, an archive operation record and a target entity operation record are respectively generated and jointly encoded and hashed to obtain a joint digest; a commitment value is generated based on the joint digest and a random number, and off-chain verification data is saved; the commitment value, a block hash and an on-chain time sequence state are input into a verifiable delay function to obtain an output value and a proof, and the output value and the proof are chained and stored, and the state is updated; when verification is performed, the commitment is recalculated, the proof is verified and the state continuity is checked, so that double-track binding, privacy-friendly storage and anti-backfill tampering are realized.

Description

Technical Field

[0001] This invention relates to the field of blockchain and digital archives management, and in particular to a blockchain-driven method and system for tracing the ownership of cross-domain archives. Background Technology

[0002] Archives serve as crucial evidence for various business activities, including collection, appraisal, storage, restoration, loan, allocation, warehousing, and regulatory auditing. With the development of information technology in business management and the digitization of archives, archives are gradually shifting from paper-based media to electronic storage and online access. Currently, relevant organizations typically build archive management systems, business management systems, and cross-departmental data exchange platforms, employing access control, operation logs, electronic signatures, trusted timestamps, and data backup to record and audit access to and changes to archival data. Simultaneously, to enhance the immutability and traceability of critical records, some solutions are beginning to introduce blockchain or consortium blockchain methods, writing key operation summaries onto the chain for post-event verification.

[0003] However, existing technologies still have shortcomings in tracing the ownership of archives across institutions, regions, and networks, mainly in the following aspects: First, the transfer trajectories are scattered across different systems, with inconsistent log formats and granularities, posing risks of tampering, loss, or post-transfer recording. Furthermore, the lack of verifiable continuous time-series constraints makes regulatory auditing and accountability difficult. Second, in scenarios involving cross-domain access and transmission of archival data alone, cross-domain sessions and key operational elements lack unified binding and consistency verification, easily leading to breaks or gaps in the ownership chain. Third, in scenarios where offline handover of target entities and online operation of archival data coexist, entity handover records and archival operation records are often out of sync, lacking a stable association mechanism, resulting in a break in the ownership association between the target entity and the archival data, making integrated traceability difficult.

[0004] Therefore, there is a need for a method and system for tracing the ownership of cross-domain archives that can address the shortcomings of existing technologies. Summary of the Invention

[0005] One objective of this invention is to propose a blockchain-driven method for tracing the ownership of cross-domain archives. This addresses the problems of existing technologies where the transfer trajectory of archives across institutions, regions, and networks is easily lost, tampered with, or subsequently added, making verification difficult. It also addresses issues such as the potential for disjointed ownership chains during cross-domain access and transmission of archives under a single-track system, and the lack of synchronization and binding between target entity handover and archive data operations under a dual-track system. The invention proposes a method that generates session identifiers at the cross-domain interface and collects cross-domain operation parameters and target entity transfer elements, generating separate archive operation records and target entity operation records. The joint hash is used to obtain a joint digest. Based on the joint digest and random number, a commitment value is generated and off-chain verification data is saved. The commitment value, block hash and on-chain time series state value are input into a verifiable delay function to generate output and proof and submit it for on-chain storage. The technical solution of combining commitment recalculation verification, delay function proof verification and time series state matching before and after to achieve traceability and verification is achieved. The present invention has the technical effects of dual-track stable binding of target entity and archive data, verifiable and privacy-friendly on-chain storage, verifiable time sequence continuity and suppression of backfilling and tampering, and convenient supervision, auditing and accountability.

[0006] This invention provides a blockchain-driven method for tracing the ownership of cross-domain archives, including: S1. Initiate a cross-domain session at the cross-domain interface and generate a current session identifier. Collect the cross-domain operation parameter set, including the subject identifier, source domain identifier, target domain identifier, file identifier, operation type, operation time, and target entity flow elements. If the target entity flow elements are missing, placeholders are used instead. S2. Obtain file data based on the file identifier and calculate the file data digest. Generate a file operation record based on the cross-domain operation parameter set and the file data digest. S3. Generate a target entity operation record based on the target entity flow elements. S4. Jointly encode the file operation record and the target entity operation record and hash them to obtain a joint digest. S5. Generate a second random number. Generate a commitment value based on the joint digest and the second random number. Associate the second random number, the joint digest, and the current session identifier and save them as off-chain verification data. S6. Read the block hash of the latest confirmed block. Read the current time series state value from the on-chain state storage area of ​​the blockchain network. Combine the commitment value, block hash, and current time series state value. For the verifiable delay function input, the verifiable delay function operation is performed to obtain the delay function output value and the delay function proof, and the delay function output value is determined to be the new time series state value; S7, submit the on-chain evidence message to the blockchain network. The on-chain evidence message includes the commitment value, the current time series state value, the delay function output value, and the delay function proof. When the blockchain network verifies the delay function proof and the time series state value carried by the on-chain evidence message is consistent with the current time series state value in the on-chain state storage area, the on-chain evidence message is written into the block and the current time series state value in the on-chain state storage area is updated to the delay function output value, and the on-chain evidence identifier is returned; S8, obtain the corresponding on-chain evidence message based on the on-chain evidence identifier, recalculate and verify the commitment value based on the off-chain verification data, verify the delay function proof, verify the temporal continuity based on the matching relationship between the time series state value in the on-chain evidence message and the delay function output value in the previous on-chain evidence message, and output the ownership tracing result.

[0007] Optionally, S1 includes: At the cross-domain interface, a cross-domain request message corresponding to the cross-domain operation is received; based on the cross-domain request message, the subject identifier, source domain identifier, target domain identifier, file identifier, operation type, operation time, and placeholder control parameters are obtained, and a first random number is generated; according to a preset encoding rule, the subject identifier, source domain identifier, target domain identifier, file identifier, operation type, operation time, and the first random number are concatenated and then calculated using a one-way hash function to obtain the current session identifier; target entity flow elements are collected at the cross-domain interface; when the target entity flow elements are not collected, placeholder generation processing is performed on the current session identifier according to the placeholder control parameters to obtain a placeholder bound to the current session identifier, and the placeholder is used as the value of the target entity flow element for subsequent steps.

[0008] Optionally, S2 includes: Based on the file identifier, the file data corresponding to the file identifier is read from the file storage system; the file data is subjected to a preset normalization process to obtain normalized file data, the normalization process includes character encoding unification, data format unification, field order fixation, and removal of non-deterministic fields that do not participate in consistency verification; Perform a cryptographic hash operation on the standardized archival data to obtain an archival data digest; The subject identifier, source domain identifier, target domain identifier, operation type, operation time, file identifier, and file data summary are assembled into a file operation record according to a preset field order.

[0009] Optionally, S3 includes: Field validation and format standardization are performed on the target entity flow elements to obtain standardized target entity flow elements; The standardized target entity flow elements are assembled into a target entity operation record according to the preset field order. The target entity operation record includes target identifier, handover entity identifier, handover location, handover time, and handover status. When S1 generates a placeholder bound to the current session identifier, the placeholder is written into the target identifier, handover entity identifier, handover location, handover time, and handover status in the target entity operation record, so that the target entity operation record maintains the same data structure as when there are target entity flow elements and is used for subsequent steps.

[0010] Optionally, S4 includes: Perform field integrity checks on both the file operation records and the target entity operation records; The fields of the file operation record and the fields of the target entity operation record are concatenated and encoded according to a preset field order to obtain the joint event plaintext; A cryptographic hash operation is performed on the plaintext of the joint event to obtain a joint digest. The cryptographic hash operation uses a hash algorithm with a fixed output length, and the preset field order is kept consistent for all cross-domain sessions so that different cross-domain sessions obtain the same joint digest under the condition of the same field value.

[0011] Optionally, S5 includes: The second random number is generated by a cryptographically secure random number generator; according to a preset commitment calculation rule, the joint digest and the second random number are combined and a cryptographic hash operation is performed to obtain the commitment value; the second random number and the joint digest are written into the off-chain verification data in a one-to-one correspondence, and the current session identifier corresponding to the cross-domain session is recorded in the off-chain verification data so that the off-chain verification data can be used for subsequent steps to recalculate the commitment value and verify consistency; wherein, the second random number is different from the first random number used to generate the current session identifier.

[0012] Optionally, S6 includes: The system retrieves the latest confirmed block from the blockchain network and reads its block hash; it reads the current time series state value from the on-chain state storage area of ​​the blockchain network; it performs deterministic encoding and concatenates the commitment value, the block hash, and the time series state value according to a preset encoding rule to obtain the delay function input value; it performs a verifiable delay function operation on the delay function input value based on preset delay parameters to obtain the delay function output value and the delay function proof; and it writes the time series state value, the delay function output value, and the delay function proof into the on-chain evidence storage message to be submitted.

[0013] Optionally, the S7 includes: The commitment value, time-series state value, delay function output value, and delay function proof are encapsulated into an on-chain evidence message according to a preset message structure. The current session identifier corresponding to the cross-domain session is written into the on-chain evidence message. The on-chain evidence message is broadcast to the blockchain network. After verifying the delay function proof, the consensus node of the blockchain network further verifies that the time-series state value carried in the on-chain evidence message is consistent with the current time-series state value in the on-chain state storage area of ​​the blockchain network. If consistent, the on-chain evidence message is written into a block, and the current time-series state value in the on-chain state storage area is updated to the delay function output value before returning the on-chain evidence identifier. The on-chain evidence identifier is used to uniquely determine the storage location of the on-chain evidence message in the blockchain network. The on-chain state storage area is either a smart contract state storage area or a world state key-value storage area deployed on the blockchain network.

[0014] Optionally, S8 includes: Based on the on-chain evidence identifier, the system reads the on-chain evidence message corresponding to the on-chain evidence identifier from the blockchain network, extracts the commitment value, time series state value, delay function output value, and delay function proof from the on-chain evidence message, and reads the current session identifier written into the on-chain evidence message; based on the current session identifier, the system reads the second random number and joint digest corresponding to the current session identifier from the off-chain verification data, recalculates the commitment value according to the preset commitment calculation rules of S5, and performs consistency verification between the recalculated commitment value and the commitment value in the on-chain evidence message; and verifies the on-chain evidence. The delayed function proof in the message is verified to confirm the correspondence between the delayed function output value and the commitment value, block hash, and time series state value; based on the preceding on-chain evidence message determined by block height in the blockchain ledger, the delayed function output value in the preceding on-chain evidence message is extracted, and the delayed function output value in the preceding on-chain evidence message is matched and verified with the time series state value in the on-chain evidence message; when the consistency verification, the verification, and the matching verification all pass, the ownership tracing result of cross-domain file transfer is output.

[0015] On the other hand, the present invention also provides a blockchain-driven cross-domain archive transfer ownership traceability system, comprising: The cross-domain session and element acquisition module is used to generate a current session identifier at the cross-domain interface, collect cross-domain operation parameter sets and target entity flow elements; the dual-track record generation module is used to obtain archive data based on the archive identifier and calculate the archive data digest to generate archive operation records, and generate target entity operation records based on the target entity flow elements; the joint digest generation module is used to jointly encode the archive operation records and the target entity operation records and hash them to obtain a joint digest; the commitment and off-chain verification module is used to generate a second random number, generate a commitment value based on the joint digest and the second random number, and associate and save the second random number, the joint digest and the current session identifier as off-chain verification data; the verifiable time series module is used to read the block hash of the latest confirmed block and the current time series state value of the on-chain state storage area, and input the commitment value, the block hash and the current time series state value into the verifiable time series data. The system verifies the delay function to obtain its output value and proof. An on-chain notarization module submits an on-chain notarization message to the blockchain network, containing the commitment value, the current time-series state value, the delay function output value, and the delay function proof. When the blockchain network verifies that the delay function proof is passed and that the time-series state value carried in the on-chain notarization message matches the current time-series state value in the on-chain state storage area, it writes the on-chain notarization message into a block, updates the current time-series state value to the delay function output value, and returns an on-chain notarization identifier. A tracing and verification module reads the on-chain notarization message based on the on-chain notarization identifier, recalculates and verifies the commitment value and the delay function proof based on the off-chain verification data, and verifies the temporal continuity based on the matching relationship between the time-series state value in the on-chain notarization message and the delay function output value in the preceding on-chain notarization message, outputting the ownership tracing result.

[0016] The beneficial effects of this invention are: 1. By generating separate records of archival operations and records of target entity operations, and performing joint coding and hashing to obtain a joint digest, a dual-track binding between archival data operations and the transfer of target entities is achieved. Even if the transfer elements of the target entity are missing, placeholders can be used to maintain the consistency of the data structure, thereby reducing the risk of the single-track ownership chain being broken and the dual-track entity and archive association being severed.

[0017] 2. By introducing random numbers into the joint digest to generate commitment values ​​and only putting the commitment values ​​on the chain, while storing the random numbers and joint digests as off-chain verification data, the commitment values ​​can be recalculated and consistently verified during the traceability and verification stage. This achieves a combination of on-chain evidence storage and off-chain unsealing verification, which not only improves the verifiability and non-repudiation of cross-domain transfer records, but also avoids directly exposing plain text file content and sensitive elements on the chain.

[0018] 3. By inputting the commitment value, block hash, and on-chain time series state value into a verifiable delay function, and constraining the on-chain writing order with the matching relationship of the state values, a verifiable continuous time series is formed, making it difficult for cross-domain transfer records to be retroactively recorded or backfilled and tampered with, thereby improving the credibility of regulatory audits and accountability. Attached Figure Description

[0019] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of a blockchain-driven method for tracing the ownership of cross-domain archives, as proposed in this invention. Detailed Implementation

[0020] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0021] refer to Figure 1 A blockchain-driven method for tracing ownership of cross-domain archives includes: S1. Initiate a cross-domain session at the cross-domain interface and generate a current session identifier. Collect the cross-domain operation parameter set, including the subject identifier, source domain identifier, target domain identifier, file identifier, operation type, operation time, and target entity flow elements. If the target entity flow elements are missing, placeholders are used instead. S2. Obtain file data based on the file identifier and calculate the file data digest. Generate a file operation record based on the cross-domain operation parameter set and the file data digest. S3. Generate a target entity operation record based on the target entity flow elements. S4. Jointly encode the file operation record and the target entity operation record and hash them to obtain a joint digest. S5. Generate a second random number. Generate a commitment value based on the joint digest and the second random number. Associate the second random number, the joint digest, and the current session identifier and save them as off-chain verification data. S6. Read the block hash of the latest confirmed block. Read the current time series state value from the on-chain state storage area of ​​the blockchain network. Combine the commitment value, block hash, and current time series state value. For the verifiable delay function input, the verifiable delay function operation is performed to obtain the delay function output value and the delay function proof, and the delay function output value is determined to be the new time series state value; S7, submit the on-chain evidence message to the blockchain network. The on-chain evidence message includes the commitment value, the current time series state value, the delay function output value, and the delay function proof. When the blockchain network verifies the delay function proof and the time series state value carried by the on-chain evidence message is consistent with the current time series state value in the on-chain state storage area, the on-chain evidence message is written into the block and the current time series state value in the on-chain state storage area is updated to the delay function output value, and the on-chain evidence identifier is returned; S8, obtain the corresponding on-chain evidence message based on the on-chain evidence identifier, recalculate and verify the commitment value based on the off-chain verification data, verify the delay function proof, verify the temporal continuity based on the matching relationship between the time series state value in the on-chain evidence message and the delay function output value in the previous on-chain evidence message, and output the ownership tracing result.

[0022] In this specific embodiment, S1 includes: At the cross-domain interface, the cross-domain session management component receives a cross-domain request message corresponding to a single cross-domain operation. This cross-domain request message uses a deterministic field structure and includes a subject identifier, source domain identifier, target domain identifier, file identifier, operation type, operation time, and placeholder control parameters. The subject identifier represents the user or system service account initiating the cross-domain operation and uses a globally unique string encoding. The source domain identifier represents the business domain of the initiator and uses a pre-assigned domain code. The target domain identifier represents the business domain of the receiver and uses a pre-assigned domain code. The file identifier represents the file object being accessed or transferred. Furthermore, it is unique within the source domain and carries the source domain prefix when crossing domains to form a globally unique identifier. The operation type represents the cross-domain behavior category and is taken from the preset enumeration set {request, transfer, copy, outbound, inbound, loan, return}. The operation time is taken from the UTC timestamp carried in the cross-domain request message and is represented as an integer in milliseconds. The placeholder control parameter is a deterministic binary parameter and includes a placeholder enable bit and a placeholder range bitmap. The placeholder enable bit is used to indicate that a placeholder must be generated when the target entity flow element is missing. The placeholder range bitmap is used to indicate the set of fields that the placeholder needs to cover in the subsequent target entity operation record. The cross-domain interface performs syntax parsing and field validation on the cross-domain request message. Field validation includes non-empty identifier field validation, existence validation of domain identifier in domain whitelist, enumeration validation of operation type belonging to the preset enumeration set, and clock drift validation that the operation time is not later than the current system time of the cross-domain interface and the deviation from the current system time does not exceed 300 seconds. If the field validation fails, the current cross-domain session is terminated and an error code is returned to avoid the generation of inconsistent session identifiers. After the field verification passes, a cryptographically secure random number generator generates a first random number. The current session identifier is then calculated by deterministically concatenating the subject identifier, source domain identifier, target domain identifier, file identifier, operation type, operation time, and the first random number according to a preset encoding rule. This preset encoding rule uses TLV encoding and fixes the field order as: subject identifier, source domain identifier, target domain identifier, file identifier, operation type, operation time, and the first random number. Each field's length is represented by a 4-byte unsigned integer to eliminate concatenation ambiguity. The first random number is 128 bits long and represented in 16-byte big-endian order. The current session identifier is generated according to the following formula: ; Where SID represents the current session identifier, This indicates a one-way hash function with SHA-256. This indicates the TLV deterministic encoding and concatenation operation. Indicates the main identifier, Indicates the source domain identifier. Indicates the target domain identifier. This indicates the file identifier; OP indicates the operation type. Indicates the operation time. Represents the first random number; After generating the current session identifier, the cross-domain interface initiates the target entity flow element collection process. The target entity flow elements are reported by the entity handover terminal or the entity supervision subsystem through the same session channel as the cross-domain interface and include the target identifier, handover subject identifier, handover location, handover time, and handover status. The cross-domain interface performs integrity verification and format verification on the target entity flow elements. The integrity verification includes the existence verification of all five fields. The format verification includes the target identifier conforming to the predefined encoding rules, the handover time being a UTC millisecond timestamp and the deviation from the operation time not exceeding 600 seconds, and the handover status belonging to the predefined enumeration set {handover initiated, handover completed, handover rejected, handover abnormal}. If the target entity flow element is not received within a preset acquisition window of 30 seconds or the verification fails, the cross-domain interface performs placeholder generation processing on the current session identifier according to the placeholder control parameters and obtains a placeholder bound to the current session identifier. The placeholder generation processing adopts a deterministic algorithm and encodes the constant prefix string "PH", the current session identifier and the placeholder control parameters in a fixed order, performs SHA-256 calculation, and extracts the first 32 hexadecimal characters to form a placeholder string, so as to ensure that the placeholder value is unique and recalculated under the same current session identifier and the same placeholder control parameters. The placeholder is written into the value position of the corresponding field of the target entity flow element according to the placeholder range bitmap, so that subsequent steps can still obtain a structurally complete target entity flow element bound to the session even in the scenario without entity elements.

[0023] In this specific embodiment, S2 includes: The file processing component identifies the file. Accessing the file storage system and reading data based on this information. In this embodiment, the corresponding archival data A is a collection of archived data (i.e., archival kernel) of cultural relics / physical objects pointed to by cross-domain circulation business instructions in different electronic archive fields to reflect the two-way kernel mechanism of business and archives. Specifically, it includes but is not limited to: three-dimensional digital twin models and interactive configuration archives of cultural relics in the field of exhibition circulation, material spectral analysis and historical restoration process parameter archives in the field of cultural relic restoration, and micro-environment time-series monitoring and three-dimensional packaging structure archives in the field of warehousing and logistics. The archival storage system is an object storage or relational database that provides accurate retrieval by archival identifier. The reading process adopts "archival identifier as primary key, take the current submitted version" as the retrieval rule and returns the original byte sequence. If the original byte sequence has a compression mark, it is decompressed according to the algorithm indicated by the mark to obtain the archival data A that participates in the normalization process. The archive data A is parsed into a set of fields and then enters a normalization process to obtain normalized archive data. The normalization process employs deterministic rules and sequentially includes character encoding standardization, data format standardization, fixed field order, and removal of non-deterministic fields not participating in consistency checks. Specifically, character encoding standardization converts all string fields to UTF-8 and performs UnicodeNFC normalization. Data format standardization converts numeric fields to decimal strings without leading zeros and boolean fields to the characters "0" or "1". Date and time fields are uniformly converted to UTC millisecond timestamp strings to match the operation time in step S1. Maintaining the same time base, the fields are rearranged according to a preset field order table and output using TLV deterministic encoding to eliminate cross-system serialization differences. The set of non-deterministic fields to be removed is defined as follows: lastAccessTime, accessCount, cacheId, tempLockId, syncTimestamp Furthermore, the data is removed from the field set immediately after parsing to avoid instability in the digest due to access behavior or caching mechanisms; In obtaining Then, a cryptographic hash operation is performed on it to obtain the archive data digest. The calculation relationship is as follows: ; in This represents a summary of archival data. This indicates a one-way hash function with SHA-256. This refers to the standardized archival data obtained according to the aforementioned standardization process; Subsequently, the document processing component processes the subject identifier according to the preset field order. Source domain identifier Target domain identifier Operation type (OP), operation time Archive identification and archive data summary Assemble into archive operation records ,in Use TLV deterministic encoding consistent with step S1 and fix the field order as follows , , OP , Furthermore, each field is written with a type number and length to ensure that there is no ambiguity in field boundaries during subsequent joint encoding.

[0024] In this specific embodiment, S3 includes: The entity element processing component receives the target entity transfer elements at the cross-domain interface. And generate target entity operation records. The The data structure includes the target identifier. , handover entity identification handover point Handover time and handover status ,in The target entity is a globally unique identifier and uses " The string format "#local serial number" is used to ensure cross-domain uniqueness and limit the total length to 64 bytes. The entity responsible for the physical handover is a globally unique identifier, and the coding rules are consistent with the entity identifier. Consistent, The handover location code is a 12-digit numeric string consisting of a 6-digit administrative division code and a 6-digit venue code. This is the decimal string representation of the UTC millisecond timestamp. It is a transition state and is taken from the enumeration set. Handover initiated, handover completed, handover rejected, handover exception ; Entity feature processing component Perform field validation and format normalization to obtain standardized target entity flow elements. The field validation includes full field existence validation and field non-empty validation for all five fields, and includes... Satisfy prefix Consistency checks and the existence check of the separator "#" Meets 12-bit numeric character set verification The timestamp format is valid and can be parsed as a non-negative integer, and it matches the operation time in step S1. Time consistency check with an absolute deviation not exceeding 600,000 milliseconds. The format normalization process includes satisfying the enumeration validation of the enumeration set. , and The encoding is uniformly converted to UTF-8 and then normalized using UnicodeNFC, with leading and trailing whitespace characters removed. Convert all strings to decimal without leading zeros and ensure that they are based on UTC time. Unified mapping to preset status code strings Corresponding to Handover initiated, handover completed, handover rejected, handover exception To ensure consistent representation across systems; When generating the placeholder PH bound to the current session identifier SID in step S1, the entity feature processing component no longer waits for or parses external entity feature reports but directly constructs the entity feature. Write the pH values ​​separately and The value positions are determined to ensure the same data structure and number of fields as when entity elements exist; Subsequently, the entity feature processing component will process the data according to the preset field order. Assembly into target entity operation record The preset field order is fixed as follows: , , , and TLV deterministic encoding is employed, and a type number and length field are written to each field to eliminate boundary ambiguity. This ensures that subsequent steps obtain structurally consistent target entity operation records that can participate in joint encoding, regardless of whether entity elements are complete or missing. .

[0025] In this specific embodiment, S4 includes: The joint summary generation component receives archive operation records. Operation logs with target entity And generate a joint summary ; The joint summary generation component first performs the following on each: and Perform field integrity verification, which compares each field item against the TLV type number sets of the two types of records. At least verify that it contains and only contains A TLV unit with seven fields, where each field appears once and the length field of each TLV unit has the same number of bytes as its value field. At least verify that it contains and only contains The TLV unit has five fields, each field appears once, and the length field of each TLV unit is consistent with the number of bytes of its value field, thus ensuring that when the placeholder PH is generated in step S1 and written in step S3... hour, It maintains the same field structure and parsable boundaries as in scenarios where all entity elements are present; After the field integrity check passes, the combined digest generation component concatenates and encodes the two records according to the preset field order to obtain the combined event plaintext. The concatenated encoding uses a deterministic encapsulation structure and a fixed writing order: protocol version number, record type identifier (ARC), ... TLV byte sequence, record type identifier OBJ, The TLV byte sequence is used, and a 4-byte unsigned integer length prefix is ​​written to each segment to achieve self-describing boundaries and eliminate cross-system parsing ambiguity. The preset field order is kept consistent across all cross-domain sessions to ensure that the same joint event plaintext is obtained under the same field value conditions. ; Joint summary generation component pair Perform a fixed-length cryptographic hash operation to obtain a joint digest. The calculation relationship is as follows: ; in Indicates a joint summary. This indicates a one-way hash function with SHA-256. This represents the joint event plaintext obtained according to the deterministic encapsulation structure and fixed write order.

[0026] In this specific embodiment, S5 includes: The commitment and off-chain verification components obtain the current session identifier (SID) and the federated digest. A second random number is then generated for commitment calculation. And form a commitment value and off-chain verification data ; The second random number Generated by a cryptographically secure random number generator, which is constructed using the HMAC-DRBG method specified in NISTSP800-90A and employs SHA-256 as its internal hash function. The seed is input once from the operating system's entropy source and its internal state is updated each time a random number is generated. The bit length is fixed at 256 bits and represented by a 32-byte big-endian byte string. The generation process and steps The first random number used to generate the current session identifier (SID) They are independent of each other and use different DRBG instances in the implementation, each maintaining its own independent seed and state to satisfy the requirements. ; The commitment and off-chain verification components will jointly summarize the commitment according to the preset commitment calculation rules. With the second random number Perform deterministic combination and cryptographic hash operation to obtain the commitment value. The deterministic combination is assembled in a fixed order, and length prefixes are written before assembly to eliminate boundary ambiguities. The commitment value Calculate using the following formula: ; in Indicates the commitment value. This indicates a one-way hash function with SHA-256. This represents the joint summary obtained in step S4. Represents the second random number. This indicates a byte string concatenation operation performed in a fixed order. After obtaining the promised value Subsequently, it is committed to constructing off-chain verification data with off-chain verification components. And write it to the off-chain verification storage using SID as the unique index key. At least include and The three items are stored using TLV deterministic encoding, with a fixed field order of SID. At the same time The commitment algorithm identifier field ALG is written in the code and its value is the string "SHA-256" to ensure that the commitment value can be recalculated using the same algorithm in the subsequent traceability and verification stage. The off-chain verification storage is a local or centralized key-value database, and unique constraints are set for the key SID to ensure a one-to-one correspondence. Furthermore, an append-only write and non-overwrite update strategy is adopted for write operations to prevent off-chain verification data from being replaced afterward, thus enabling subsequent steps to stably retrieve data based on the SID. and Recalculate the commitment value Complete consistency verification.

[0027] In this specific embodiment, S6 includes: The commitment value is obtained from the verifiable time series module. The output value of the delay function is generated later. Proof with delay function And determine the new time series state values; The verifiable time series module reads the latest confirmed block and extracts its block hash through the block query interface of the blockchain node. The latest confirmed block is defined as a confirmed block that lags behind the latest height on the chain by at least 6 block heights to avoid fork rollback affecting input consistency; The verifiable time series module reads the current time series state value through the smart contract state storage area or the world state key-value storage area. ,in The value field corresponding to the fixed key name TS_STATE is a fixed-length 32-byte string. During chain initialization, TS_STATE is set to an all-zero string to form a reproducible initial state. The verifiable time series module constructs the delay function input values ​​according to deterministic coding rules. The deterministic encoding rule uses TLV encoding and fixes the field order as follows: Furthermore, each field is written with a type number and length, and a length prefix is ​​written in big-endian order to eliminate concatenation ambiguity. Then, for... Performing SHA-256 yields a 32-byte digest, which is used as a seed for the delay function. This seed is then mapped to the base through a "hash to group element" process. The hashing to group element process interprets the seed as a non-negative integer according to deterministic rules and modulo the RSA. The modulo operation is used to obtain candidate values, and the candidate values ​​are either 0 or 1 or... If the seeds are not coprime, append a 1-byte counter to the seed and rehash until the condition is met. and of To ensure that group operations are effective; The verifiable time series module calls the verifiable delay function and exposes the parameters. Perform a delay operation to obtain the output value of the delay function. ,in It is an RSA modulus of length 2048 bits, generated and solidified in the constant area of ​​the smart contract during the system deployment phase, and its factors are destroyed after generation to ensure the unknown order property. The delay parameter has a value of and corresponding The computational complexity of the consecutive squaring operations, and the delay operation satisfying the following relation: ; in This represents the output value of the delay function. This represents the base obtained from the hash-to-group element process. Indicates the delay parameter. Represents the RSA modulus. Represents modulo operation; The verifiable time series module constructs a proof of the delay function based on the Wesolowski proof. The proof that challenging prime numbers is achieved by... The deterministic hash is obtained and selected through a primality test, as proven by... By The challenge prime number is obtained by performing quotient-remainder decomposition and calculating the corresponding quotient power, thus enabling on-chain verifiers to perform verification without repetition. Verification under the premise of consecutive squares A consistent correspondence with the input; The verifiable time series module will and Write the on-chain evidence storage message to be submitted and This is determined as the new time series state value.

[0028] In this specific embodiment, S7 includes: Based on the commitment value by the on-chain evidence storage module And in step S6, the current time series status value of the message to be submitted is written. Delay function output value Proof of delay function Constructing on-chain evidence storage messages and in Write the current session identifier (SID) corresponding to this cross-domain session into the blockchain to achieve on-chain evidence storage and off-chain verification data. The index association, where TLV deterministic encoding is used with a fixed field order: protocol version number, SID, Each field is written with a type number and length, and the length prefix is ​​written in big-endian order to eliminate boundary ambiguity and ensure that different nodes get consistent parsing results for the same message. The on-chain evidence storage module will Encapsulated as a blockchain transaction call and broadcast to the consensus nodes of the blockchain network, the transaction call points to the notarization entry function `storeEvidence(SID, ...)` of the notarization smart contract. And the transaction load is byte sequence; When executing the notarization entry function, the consensus node reads the current time-series state value from the fixed key name TS_STATE in the on-chain state storage area. and with Carry Performing byte-level consistency comparisons is only possible when... The delayed function proof verification will only continue when the condition is met, in order to form write order constraints and suppress backfilling. During the proof and verification phase, the consensus nodes use the current block height for execution. Determine the reference block height And read the height as Reference block hash To ensure consistency with the latest confirmed block hash used in step S6, the delay function input value is then reconstructed according to the deterministic encoding rules consistent with step S6. And reconstruct the base data accordingly. and calling the same set of public parameters Proof of the delay function Perform verification to confirm Carry With input The correspondence between them holds true; If and only if the proof of the delay function passes and When the consistency comparison passes, the consensus node will Write the transaction receipt event area of ​​the current block and remove the TS_STATE from the on-chain state storage area. Atoms updated to The process proceeds by completing the time-series state, and then the blockchain network returns an on-chain notarized identifier (EID). The EID is determined by a triple consisting of the block height, transaction hash, and event sequence number, and can uniquely locate the user. Storage location in the blockchain ledger.

[0029] In this specific embodiment, S8 includes: The traceability and verification module receives the on-chain evidence identifier EID and completes on-chain evidence retrieval, off-chain unsealing verification, delay function proof verification, and time sequence continuity verification before outputting the ownership traceability result. The traceability and verification module obtains the evidence storage block height based on EID parsing. Transaction hash With event number And through the block query interface of the blockchain node at height [height missing] Within the block With IDX Locating and reading on-chain evidence storage messages ,from Extract the current session identifier (SID) and commitment value. Time series state values Delay function output value Proof with delay function And perform TLV structure integrity verification to confirm that the set of field type numbers and the order of fields conform to the protocol version definition and that the length and number of bytes of each field are consistent; The traceability and verification module uses the SID as a unique index key to access the off-chain verification storage and read the off-chain verification data that corresponds one-to-one with the SID. ,from Extract the second random number With joint abstract And verify The commitment algorithm identifier field ALG is set to "SHA-256" to lock the recalculation algorithm, and then the commitment value is recalculated according to the preset commitment calculation rules. and on-chain commitment value Perform byte-level consistency verification, where the recompile relationship is: ; in This represents the recalculated commitment value. This indicates a one-way hash function with SHA-256. Indicates a joint summary. Represents the second random number. This indicates a byte string concatenation operation performed in a fixed order. After the commitment consistency check passes, the traceability verification module verifies the delay function. Perform verification to confirm With input The correspondence, in which the traceability verification module is based on Used as a reference to determine the height of the reference block. And read the height as block hash The delay function input value is reconstructed according to the deterministic encoding rule consistent with the "latest confirmed block hash" selection rule during on-chain writing, and then according to the deterministic encoding rule consistent with step S6. And reconstruct the base data accordingly. and call the public parameters consistent with on-chain verification. right Perform verification to ensure that no substitutions are found. Alternatively, falsified evidence can be achieved by adjusting the input fields; After the delay function proof verification is passed, the traceability verification module performs a timing continuity check and locates the adjacent blocks in the blockchain ledger according to the block height order. Previous on-chain evidence storage messages The location rule is to search backwards by event number within the same block. Time to retrieve event sequence number Corresponding message and in Backtracking to the last provenance event in the previous block until the record is obtained. and from Extract its delay function output value Later and Carry Perform byte-level matching and verification to confirm that the time series state progression satisfies the continuity constraint that "the preceding output equals the following input"; When the commitment consistency check, the delay function proof verification, and the timing continuity check pass, the traceability verification module outputs a valid ownership traceability result for cross-domain file transfer and sets the SID and EID together. The key fields obtained from the parsing are returned as traceability credentials. When any verification fails, the ownership traceability result is output as invalid and the corresponding failure reason and inconsistency field identifier are returned for audit evidence collection.

[0030] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

[0031] This invention employs a combined mechanism of dual-track joint hash binding, multimodal commitment, and verifiable time-series anti-backfilling to address the technical challenges of cross-domain data transfer, such as "easily lost, easily tampered with, easily supplemented and difficult to verify" and "disconnection of the single-track ownership chain, and difficulty in binding asynchronous entities and archives." Specifically, the cross-domain session generates a session identifier and collects cross-domain operation parameters at the interface, simultaneously forming archive operation records and target entity operation records. A joint digest is obtained through deterministic joint encoding and hashing, binding archive data operations and target entity handover within the same digest. The joint digest is then used to generate a commitment value via random number generation and uploaded to the blockchain, ensuring that only verifiable cryptographic credentials are stored on the chain without exposing plaintext elements. Subsequently, the commitment can be recalculated using off-chain verification data and compared with the on-chain result for verifiable and non-repudiable ownership traceability. Furthermore, the commitment value, along with the on-chain time-series state value and block hash, are input into a verifiable delay function, and on-chain state consistency is used as the writing condition to form a verifiable continuous time-series chain. This suppresses the backfilling and order tampering of cross-domain transfer records, thereby improving the credibility of regulatory audits and accountability.

[0032] In terms of algorithm structure, this invention makes adaptive improvements to address the pain points of asynchronous dual-track systems and heterogeneous cross-domain data: First, when the target entity's transfer elements are missing, a placeholder bound to the session identifier is introduced, while maintaining the data structure of the target entity's operation records. This allows single-track and dual-track scenarios to be processed uniformly under the same joint summary generation path, reducing the probability of a break in the association between the entity and the archive's ownership. Second, standardized processing and deterministic encoding with fixed field order are introduced for archive data and entity elements, reducing summary inconsistencies caused by cross-system format differences and enhancing the stability of cross-domain verification. Third, the committed random number and the session identifier-generated random number are separated, and dual verification is formed on the chain through matching the time-series state values ​​before and after and proving with a delay function. This enables both privacy-friendly lightweight evidence storage and time-series continuity constraints. Fourth, in cross-domain transfers, by generating separate records of archival operations (such as 3D twins, restoration mass spectrometry, monitoring microenvironment, etc., heterogeneous electronic archive kernels of cultural relics) and records of target entity operations (such as the business kernel of offline physical handover and transfer), and performing joint coding and hashing to obtain a joint summary, the dual-track binding of archival data operations and target entity handover and transfer is realized. Even if the elements of target entity transfer are missing, the data structure can be kept consistent by using placeholders, thereby reducing the risk of the single-track ownership chain being disconnected and the dual-track entity and archive association being broken. This greatly broadens the applicability and stability of the system for cross-domain confirmation of complex cultural relic digital assets, so as to improve the credibility of supervision, auditing and accountability in complex business scenarios such as cross-institutional and cross-regional transfer of cultural relics.

Claims

1. A blockchain-driven method for tracing ownership of cross-domain archives, characterized in that, include: S1. Initiate a cross-domain session at the cross-domain interface and generate the current session identifier. Collect the cross-domain operation parameter set, including the subject identifier, source domain identifier, target domain identifier, file identifier, operation type and operation time, as well as the target entity flow elements. If the target entity flow elements are missing, placeholders will be used instead. S2. Obtain archive data based on the archive identifier and calculate the archive data summary. Generate archive operation records based on the cross-domain operation parameter set and the archive data summary. S3. Generate target entity operation records based on target entity flow elements; S4. Perform joint encoding and hashing on the file operation record and the target entity operation record to obtain a joint digest; S5. Generate a second random number, generate a commitment value based on the joint digest and the second random number, and associate the second random number, the joint digest and the current session identifier to save it as off-chain verification data; S6. Read the block hash of the latest confirmed block, read the current time series state value from the on-chain state storage area of ​​the blockchain network, take the commitment value, block hash and current time series state value as input to the verifiable delay function, execute the verifiable delay function operation to obtain the delay function output value and delay function proof, and determine the delay function output value as the new time series state value. S7. Submit an on-chain evidence message to the blockchain network. The on-chain evidence message includes a commitment value, the current time series state value, the delay function output value, and the delay function proof. When the blockchain network verifies that the delay function proof is passed and the time series state value carried by the on-chain evidence message is consistent with the current time series state value in the on-chain state storage area, it writes the on-chain evidence message into a block and updates the current time series state value in the on-chain state storage area to the delay function output value, and returns the on-chain evidence identifier. S8. Obtain the corresponding on-chain evidence storage message based on the on-chain evidence storage identifier, recalculate and verify the commitment value based on the off-chain verification data, verify the delay function proof, verify the temporal continuity based on the matching relationship between the time series state value in the on-chain evidence storage message and the delay function output value in the previous on-chain evidence storage message, and output the ownership tracing result.

2. The blockchain-driven method for tracing ownership of cross-domain archives as described in claim 1, characterized in that, S1 includes: Receive cross-domain request messages corresponding to cross-domain operations at the cross-domain interface; Based on the parsing of the cross-domain request message, the subject identifier, source domain identifier, target domain identifier, file identifier, operation type, operation time, and placeholder control parameters are obtained, and a first random number is generated; The current session identifier is obtained by concatenating the subject identifier, the source domain identifier, the target domain identifier, the file identifier, the operation type, the operation time, and the first random number according to the preset encoding rules and then calculating the result using a one-way hash function. Collect target entity flow elements at the cross-domain interface; When the target entity flow element is not collected, the current session identifier is processed by placeholder generation according to the placeholder control parameter to obtain a placeholder bound to the current session identifier, and the placeholder is used as the value of the target entity flow element for subsequent steps.

3. The blockchain-driven method for tracing ownership of cross-domain archives as described in claim 1, characterized in that, S2 include: Based on the file identifier, retrieve the file data corresponding to the file identifier from the file storage system; The archive data is subjected to a preset normalization process to obtain normalized archive data. The normalization process includes character encoding standardization, data format standardization, field order fixation, and removal of non-deterministic fields that do not participate in consistency verification. Perform a cryptographic hash operation on the standardized archival data to obtain an archival data digest; The subject identifier, source domain identifier, target domain identifier, operation type, operation time, file identifier, and file data summary are assembled into a file operation record according to a preset field order.

4. A blockchain-driven method for tracing ownership of cross-domain archives as described in claim 1, characterized in that, S3 include: Field validation and format standardization are performed on the target entity flow elements to obtain standardized target entity flow elements; The standardized target entity flow elements are assembled into a target entity operation record according to the preset field order. The target entity operation record includes target identifier, handover entity identifier, handover location, handover time, and handover status. When S1 generates a placeholder bound to the current session identifier, the placeholder is written into the target identifier, handover entity identifier, handover location, handover time, and handover status in the target entity operation record, so that the target entity operation record maintains the same data structure as when there are target entity flow elements and is used for subsequent steps.

5. A blockchain-driven method for tracing ownership of cross-domain archives as described in claim 1, characterized in that, S4 include: Perform field integrity checks on both the file operation records and the target entity operation records; The fields of the file operation record and the fields of the target entity operation record are concatenated and encoded according to a preset field order to obtain the joint event plaintext; A cryptographic hash operation is performed on the plaintext of the joint event to obtain a joint digest. The cryptographic hash operation uses a hash algorithm with a fixed output length, and the preset field order is kept consistent for all cross-domain sessions so that different cross-domain sessions obtain the same joint digest under the condition of the same field value.

6. A blockchain-driven method for tracing ownership of cross-domain archives as described in claim 1, characterized in that, S5 include: The second random number is generated by a cryptographically secure random number generator; According to the preset commitment calculation rules, the joint digest is combined with the second random number and then a cryptographic hash operation is performed to obtain the commitment value; Write the second random number and the joint digest into the off-chain verification data in a one-to-one correspondence, and record the current session identifier corresponding to the cross-domain session in the off-chain verification data so that the off-chain verification data can be used in subsequent steps to recalculate the commitment value and verify consistency. The second random number is different from the first random number used to generate the current session identifier.

7. A blockchain-driven method for tracing ownership of cross-domain archives as described in claim 1, characterized in that, S6 include: Obtain the latest confirmed block from the blockchain network and read the block hash of the latest confirmed block; Read the current time series state value from the on-chain state storage area of ​​the blockchain network; The commitment value, the block hash, and the time series state value are deterministically encoded and concatenated according to a preset encoding rule to obtain the delay function input value; Based on preset delay parameters, a verifiable delay function operation is performed on the input value of the delay function to obtain the output value of the delay function and the proof of the delay function. The time series state value, the delay function output value, and the delay function proof are then written into the on-chain evidence storage message to be submitted.

8. A blockchain-driven method for tracing ownership of cross-domain archives as described in claim 1, characterized in that, S7 includes: According to the preset message structure, the commitment value, time series state value, delay function output value and delay function proof are encapsulated into an on-chain evidence storage message, and the current session identifier corresponding to the cross-domain session is written into the on-chain evidence storage message. Broadcast the on-chain evidence storage message to the blockchain network; After verifying the delay function proof, the consensus node of the blockchain network further verifies that the time series state value carried in the on-chain evidence storage message is consistent with the current time series state value in the on-chain state storage area of ​​the blockchain network. If they are consistent, the on-chain evidence storage message is written into a block, and the current time series state value in the on-chain state storage area is updated to the output value of the delay function before returning the on-chain evidence storage identifier. The on-chain evidence storage identifier is used to uniquely determine the storage location of the on-chain evidence storage message in the blockchain network. The on-chain state storage area is a smart contract state storage area or a world state key-value storage area deployed on the blockchain network.

9. A blockchain-driven method for tracing ownership of cross-domain archives as described in claim 1, characterized in that, S8 includes: Based on the on-chain evidence identification, read the on-chain evidence message corresponding to the on-chain evidence identification from the blockchain network, extract the commitment value, time series state value, delay function output value and delay function proof from the on-chain evidence message, and read the current session identifier written to the on-chain evidence message; Based on the current session identifier, the second random number and joint digest corresponding to the current session identifier are read from the off-chain verification data. The commitment value is recalculated according to the preset commitment calculation rules of S5. The recalculated commitment value is then checked for consistency with the commitment value in the on-chain evidence storage message. Verification is performed on the delayed function proof in the on-chain evidence message to confirm the correspondence between the delayed function output value and the commitment value, block hash, and time series state value; Based on the preceding on-chain evidence message that is determined in the blockchain ledger according to the block height order and is immediately before the on-chain evidence message, the delay function output value in the preceding on-chain evidence message is extracted, and the delay function output value in the preceding on-chain evidence message is matched and verified with the time series state value in the on-chain evidence message. When the consistency check, the verification, and the matching check all pass, the ownership tracing result of the cross-domain file transfer is output.

10. A blockchain-driven cross-domain archive transfer ownership traceability system, used to execute the blockchain-driven cross-domain archive transfer ownership traceability method according to any one of claims 1 to 9, characterized in that, include: The cross-domain session and feature acquisition module is used to generate the current session identifier at the cross-domain interface, and to collect the cross-domain operation parameter set and the target entity flow elements. The dual-track record generation module is used to obtain archive data based on the archive identifier and calculate the archive data summary to generate archive operation records, and to generate target entity operation records based on the target entity flow elements; A joint digest generation module is used to jointly encode the file operation record and the target entity operation record and hash them to obtain a joint digest. The commitment and off-chain verification module is used to generate a second random number, generate a commitment value based on the joint digest and the second random number, and associate and save the second random number, the joint digest and the current session identifier as off-chain verification data. The verifiable time series module is used to read the block hash of the latest confirmed block and the current time series state value of the on-chain state storage area, and input the commitment value, the block hash and the current time series state value into the verifiable delay function to obtain the delay function output value and the delay function proof; The on-chain evidence storage module is used to submit an on-chain evidence storage message to the blockchain network, which includes the commitment value, the current time series state value, the delay function output value, and the delay function proof. When the blockchain network verifies that the delay function proof is passed and that the time series state value carried by the on-chain evidence storage message is consistent with the current time series state value in the on-chain state storage area, it writes the on-chain evidence storage message into a block, updates the current time series state value to the delay function output value, and returns the on-chain evidence storage identifier. The traceability and verification module is used to read the on-chain evidence message based on the on-chain evidence identifier, recalculate and verify the commitment value based on the off-chain verification data, verify the delay function proof, and verify the temporal continuity based on the matching relationship between the time series state value in the on-chain evidence message and the delay function output value in the previous on-chain evidence message, and output the ownership traceability result.

Images