A shared service link provenance management method and system

Abstract

The application belongs to the technical field of information sharing service, and particularly relates to a shared service link traceability management method and system. The method and system introduce a concurrent branch traceability record and trigger checkpoint weaving mechanism, realize high-concurrency writing of traceability records under the premise of retaining the integrity of a cryptographic chain, solve the fundamental technical contradiction between cryptographic chain dependence and high-concurrency processing, and realize efficient auditing of a traceability chain through a multi-granularity scalable verification mechanism, so that the scheme is more suitable for a high-concurrency scenario.

Description

Technical Field

[0001] This invention relates to the field of information sharing service technology, specifically to a method and system for tracing and managing shared service links. Background Technology

[0002] In some data-sharing fields, cross-departmental and cross-level collaborative data access is becoming increasingly frequent. Taking traffic management as an example, vehicle lifecycle management involves multiple stages such as registration, insurance, and scrapping, corresponding to multiple management departments and business systems. Departments achieve controlled access to data resources in business systems through shared service links. With increasingly stringent data security and compliance requirements, traceability of shared service link access has become a critical requirement: once a shared service link is distributed to a department or user, the administrator needs to be able to trace "when, by whom, from which device, under what network environment, which data fields were accessed, and what operations were performed." In the event of data leakage or unauthorized access, it is necessary to provide the auditing department with access traceability proof that has cryptographic integrity verification capabilities and is tamper-proof.

[0003] Existing technologies for access tracing mainly fall into two categories. The first is log-based tracing: access operations are recorded in a log database for later querying. Its drawback is that logs are stored in a centralized database, allowing authorized administrators to modify or delete them afterward, making the credibility of tracing evidence dependent on trust in the individuals involved. The second is blockchain-based tracing: access records are hashed and uploaded to the blockchain, leveraging its tamper-detectability capabilities. Its drawbacks include the need to deploy and maintain a blockchain network, resulting in high system complexity and operational costs, and transaction confirmation delays.

[0004] Meanwhile, both log-based and blockchain-based traceability methods frequently utilize cryptographic traceability chains. A cryptographic traceability chain refers to a cryptographic structure built using hash chains (such as SHA-256 concatenated blocks) and digital signatures (such as ECDSA / SM2) to ensure the sequential association and authenticity of data sources. Cryptographic traceability chains provide mathematical guarantees for data integrity, authentication, and tamper-proofing.

[0005] Based on the application of cryptographic tracing chains, the inventors discovered through research that when applying cryptographic chain structures to high-concurrency access scenarios, there is still a key technical contradiction that has not been addressed or resolved by existing technologies: The core anti-tampering mechanism of the cryptographic tracing chain is that each tracing record contains the hash value (prevHash) of the previous record, forming a chain-like dependency. The cryptographic security of this structure is based on the strict serial dependency that "the later record depends on the complete content of the previous record." However, in high-concurrency scenarios (such as hundreds of staff members on duty simultaneously across the province, querying electric bicycle records through the same shared service link), a large number of concurrent access requests are generated. If the tracing records are forced to be generated serially according to the prevHash dependency, the system throughput will be limited by the computation and write latency of a single tracing record, forming a serious performance bottleneck. Conversely, if the strict prevHash chain dependency is abandoned in order to improve concurrency performance, the tamper-proof integrity of the tracing chain cannot be guaranteed.

[0006] The essence of this contradiction lies in the fundamental conflict between the "strict serial dependency" of cryptographic chain structures and the "parallel processing requirements" of high-concurrency scenarios. Existing cryptographic chain structures such as standard hash chains and blockchains do not provide a solution to this contradiction; blockchains achieve intra-block parallelism by batch packaging transactions, but the actual arrival order of concurrent requests is not necessarily consistent with the final packaging order, making it difficult to directly preserve the true temporal relationship between concurrent accesses, and the packaging process itself (block production) is still serial. Summary of the Invention

[0007] To address the issue that existing cryptographic chain data structures are unsuitable for high-concurrency scenarios, this invention provides a shared service link tracing management method. This method introduces concurrent forking tracing records and a triggered checkpoint weaving mechanism to achieve high-concurrency writing of tracing records while preserving the integrity of the cryptographic chain. Simultaneously, it utilizes a multi-granularity scalable verification mechanism to achieve efficient auditing of the tracing chain, making the solution more suitable for high-concurrency scenarios. This application also provides a shared service link tracing management system.

[0008] The technical solution of this invention is as follows: a method for tracing and managing shared service links, comprising the following steps: S1: Build a shared service link traceability management system, and define the data structure of traceability records and the organization structure of traceability data in the system; The data structure of the traceability record includes the following fields: record sequence number seqNum, checkpoint sequence number cpSeq, access timestamp, access subject identifier clientId, operation type operationType, data scope fingerprint dataScopeFingerprint, access environment digest envDigest, key time period number epoch, client signature clientSignature, system signature systemSignature, and record hash value recordHash. The traceability data is organized in a two-layer structure based on a woven checkpoint sequence and an interval record layer. The weave checkpoint sequence is formed by a unidirectional linking of weave checkpoints in chronological order. Each weave checkpoint contains a segmented weave digest of all traceability records generated within that checkpoint interval. The interval record layer is temporarily composed of multiple traceability records generated concurrently within the same checkpoint interval. There is no prevHash dependency between the traceability records within the interval record layer, allowing for parallel generation. S2: When a client needs to create a shared service link, it submits a link creation request to the shared service link traceability management system; after the system verifies the client's permissions, it creates the link and generates the initial weaving checkpoint W_0; The founding weaving checkpoint W_0 contains the following fields: checkpoint sequence number cpSeq=0, checkpoint closing timestamp cpTimestamp, the interval digest weaveDigest generated by the unique founding trace record P_0 of checkpoint W_0 through segmented weaving, recordCount=1, the hash of the previous checkpoint prevCheckpointHash, the list of public keys for the key period epochPublicKeys, and the checkpoint hash value checkpointHash; Among them, checkpointHash = HASH(cpSeq || cpTimestamp || weaveDigest ||recordCount || prevCheckpointHash ||epochPublicKeys); The hash of the previous checkpoint corresponding to the founding checkpoint W_0, prevCheckpointHash, is a 32-byte all-zero value. The epochPublicKeys list includes: the client's initial public key PK_0 and the system public key; Set the link identifier linkId to the checkpointHash value of the initial weaving checkpoint W_0, so that the link identifier is cryptographically bound to the initial state of the traceability chain, and realizes a one-to-one cryptographic correspondence between the link identifier and the traceability chain. S3: The system returns the generated shared service link to the client; The access address for the shared service link is: https: / / {system domain name} / api / traceable-link / {linkId}; S4: When a client initiates a data access request through the shared service link, the system performs concurrent traceability record generation and checkpoint trigger weaving operations; S5: When it is necessary to trace and audit the access history of a shared service link, multi-granularity scalable verification supports the auditor to select the verification depth according to actual needs; S6: When the lifecycle of the shared service link ends, the system performs a sealing operation on the traceability chain; The lifecycle of a shared service link is determined to have ended if any of the following conditions are met. The link expires, the maximum number of accesses is reached, or it is manually revoked by the administrator; The sealing operation includes: performing a forced weaving checkpoint operation, weaving all unweaved traceability records within the last checkpoint interval into a termination weaving checkpoint W_term; the termination weaving checkpoint W_term additionally contains a chain state fingerprint chainStateFingerprint, the calculation formula of which is: chainStateFingerprint = HASH(W_0.checkpointHash || W_1.checkpointHash|| ... || W_{term-1}.checkpointHash); The checkpointHash sequence of all weave checkpoints in the entire weave checkpoint sequence before the terminating weave checkpoint W_term is concatenated in ascending order by checkpoint number cpSeq and then hashed. The formula for calculating the checkpoint hash value checkpointHash of the terminating weave checkpoint W_term is correspondingly expanded to: W_term.checkpointHash =HASH(cpSeq || cpTimestamp || weaveDigest || recordCount || prevCheckpointHash || epochPublicKeys || chainStateFingerprint); Once the sealing is complete, a sealing certificate is generated, the link is marked as sealed, and any new access requests and appending of traceability records are rejected.

[0009] Its further features are: In step S1, the time window length T_window of the checkpoint interval is an adaptive parameter, and the adaptive adjustment method for the time window length is as follows: The average number of visits, C_avg, is defined as the ratio of the sum of the number of records in the most recent K intervals to the sum of the time spans. The system monitors the average access volume C_avg within the interval of the most recent K weaving checkpoints; when C_avg exceeds the preset high concurrency threshold C_high, the T_window is shortened; when C_avg is lower than the preset low concurrency threshold C_low, the T_window is extended. The T_window is between the preset lower limit T_min and the upper limit T_max. In step S1, the method for generating the interval summary weaveDigest includes the following steps: s11: The system sorts all traceability records within the current checkpoint interval in ascending order according to the record number seqNum, and divides them into several weaving segments Segment_i according to the preset segment length L; s12: For each weaving segment, the system concatenates the seqNum of each record in the segment with the recordHash in ascending order of seqNum and performs hash calculation to obtain the sequence number binding digest indexDigest_i; The segmentDigest_i for each weaving segment is calculated as follows: segmentDigest_i = HASH(segmentSeq || firstSeqNum || lastSeqNum ||recordCount_i || indexDigest_i); Where segmentSeq is the weaving segment number, firstSeqNum and lastSeqNum are the first and last record numbers in the weaving segment, respectively, and recordCount_i is the number of records in the weaving segment; s13: After obtaining the segmentDigest_i of all weaving segments, the system concatenates each segmentDigest_i in ascending order of segmentSeq and calculates the interval weaving summary: weaveDigest = HASH(cpSeq || segmentCount || segmentDigest_1 || segmentDigest_2 || … || segmentDigest_m); Where segmentCount is the number of weaving segments within the current checkpoint interval, and m is the total number of weaving segments; s14: Write the weaveDigest to the weave checkpoint and participate in the calculation of checkpointHash; Step S4 specifically includes the following steps: a1: Extract the link identifier linkId from the shared service link, and locate the source chain corresponding to the link and its current active range; The active interval refers to the checkpoint interval that is currently receiving new traceability records and has not yet been closed; there is only one active interval for the same traceability chain at any given time. a2: Check if the current active zone can still receive new records; detection methods include: Confirmation Time: Confirm that the time window for the current active period has expired. If it has expired, new records cannot be accepted; otherwise, new records can be accepted. Confirm capacity: Confirm that the cumulative number of records in the current active range has reached the threshold N_max. If the threshold has been reached, new records cannot be accepted; otherwise, new records can be accepted. If the current active interval cannot accept new records, first perform the weaving checkpoint operation in step a3 to close the current active interval and create a new active interval, and then use the newly created active interval as the current active interval before performing step a4. If the current active range can still accept new records, proceed to step a4; a3: The specific process of the weaving checkpoint operation is as follows: a31: Sort the hash values ​​of all trace records within the current checkpoint interval in ascending order according to the record number to obtain the sorted recordHash sequence; a32: The system divides the sorted source records into several weaving segments Segment_i according to the preset segment length L, and calculates the sequence number binding digest indexDigest_i and segment digest segmentDigest_i; The method for calculating the sequence number bound to the digest indexDigest_i is as follows: First, pair the seqNum of each record in Segment_i with the recordHash to obtain a pair. Then, concatenate all the pairs in the segment in ascending order of seqNum and perform hash calculation to obtain indexDigest_i. The segment digest segmentDigest_i is calculated as follows: segmentDigest_i = HASH(segmentSeq || firstSeqNum || lastSeqNum || recordCount_i || indexDigest_i); the system concatenates each segmentDigest_i in ascending order of segmentSeq and calculates weaveDigest = HASH(cpSeq || segmentCount || segmentDigest_1 || segmentDigest_2 || … || segmentDigest_m); a33: Calculate the checkpoint hash value of the current weave checkpoint: checkpointHash = HASH(cpSeq ||cpTimestamp || weaveDigest || recordCount || prevCheckpointHash||epochPublicKeys); Where, prevCheckpointHash is the checkpointHash of the previous weaving checkpoint; a34: Append the current knitting checkpoint to the end of the knitting checkpoint sequence; a35: Start a new active range: increment cpSeq, reset the time window, clear the buffer, and initialize empty weaving segment cache and range weaving summary state; a4: Within the current active interval, generate a source trace record for this access; the generation of the source trace record is independent of the generation of source trace records for other concurrent accesses within the same checkpoint interval, with no prevHash dependency, and each source trace record supports parallel generation; a5: After each traceability record is generated, perform the following operations sequentially on the generated traceability record. a51 dual signature: First, the accessing client uses its current key period private key SK_epoch to sign the core field, generating clientSignature; after the system verifies the validity of clientSignature, it uses the system traceability signing private key to sign (core field || clientSignature), generating systemSignature; a52 record hash calculation: After the double signature is completed, the system will concatenate the traceability record fields other than the recordHash field itself in a preset order and calculate the recordHash; subsequent writes to the buffer and weaving digest inputs are based on this recordHash; The core fields include: seqNum, cpSeq, timestamp, clientId, operationType, dataScopeFingerprint, envDigest, and epoch; where clientId is the identifier of the access subject corresponding to this access request, and is not necessarily the same as the identifier of the creator of the shared service link. a53 Write Buffer: After the signature and recordHash calculations are completed, the traceability record and its seqNum and recordHash are written to the record buffer of the active region for the generation of weaveDigest when the checkpoint is closed; a54 Returns Traceability Credentials: Returns the traceability credentials for this access to the client. The traceability credentials include: the record hash value of this traceability record and the current record sequence number seqNum; a55 capacity check: After writing is completed, if the cumulative number of records in the active range has reached N_max, an a3 weaving operation is immediately triggered to create a brand new active range; a6: Request forwarding: According to the routing rules corresponding to the shared service link, forward this data access request to the target business system, and attach a source identification identifier when forwarding, so that the business system can associate the source identification record in its own log; the source identification identifier includes: linkId and seqNum of this access; It also includes a private key management method; the private key management method adopts a forward-secure key evolution mechanism, specifically including the following steps: b1: Divide the entire lifecycle of the system into several key periods, each key period corresponding to a unique period number epoch; b2: Based on the elliptic curve public key cryptography algorithm, the client generates an initial key pair (SK_0, PK_0) of an n-order signature curve during the initial registration using a signature key generation algorithm, where SK_0 is a random integer within the range of legal private key values ​​specified by the signature algorithm, and n is the order of the signature recommendation curve; PK_0 = SK_0 · G, where G is the base point of the signature elliptic curve; PK_0 is stored in the client certificate of the system after being signed by the CA, and serves as the trust anchor point of the client's public key chain; b3: Upon entering a new key period, the client performs the following key evolution operation: b31: The new private key for the current time period is obtained by iterating over the current private key using the one-way hash function and modulo n: SK_epoch = HASH(SK_{epoch-1}) mod n; if the result does not fall within the range of legal private key values ​​specified by the signature algorithm, then HASH(SK_{epoch-1} || 0x01) mod n is used to recalculate until the new private key falls within the range of legal private key values ​​specified by the signature algorithm; n is the order of the signature recommendation curve; b32: Calculate the public key for the corresponding time period: PK_epoch = SK_epoch · G; b33: Submit the tuple (epoch, PK_epoch) to the system through the established secure channel between the client and the system; b34: The system records the triple (clientId, epoch, PK_epoch) in the epochPublicKeys field of the currently active checkpoint, so that when the checkpoint is closed and participates in the weaving of the checkpoint sequence, PK_epoch is cryptographically anchored to the weaving checkpoint sequence. b35: The client overwrites and deletes SK_{epoch-1} in the secure storage area, retaining only SK_epoch for the traceability record signature of the current time period; b4: In each traceability record, the client signature clientSignature is signed using the private key SK_epoch corresponding to the key period when the record was generated, and the key period used for signing is marked in the traceability record by the epoch field. b5: During subsequent audit verification of clientSignature, the verifier reads PK_epoch from the epochPublicKeys field of the weaving checkpoint that records the epoch public key in the weaving checkpoint sequence based on the epoch field in the traceability record, and uses PK_epoch to perform signature verification of clientSignature. The weaving checkpoint operation is initiated based on preset checkpoint trigger conditions; Triggering condition 1: The time window for the current active period has expired; Triggering condition two: The cumulative number of traceability records within the current active range has reached the threshold N_max; Triggering condition three: The system receives a manual instruction to trigger the weaving process; If any one of the conditions is met, the weaving checkpoint operation is triggered; The multi-granularity scaling verification in step S5 includes: Granularity 1 is the weaving-level verification: it only verifies the chain consistency of checkpointHash of each weaving checkpoint in the weaving checkpoint sequence, that is, it verifies whether the prevCheckpointHash of each checkpoint is equal to the checkpointHash of the previous checkpoint, and verifies whether the checkpointHash of each checkpoint is equal to the hash calculation result of its constituent fields; the time complexity of weaving-level verification is O(m), where m is the number of weaving checkpoints, and m is much smaller than the total number of accesses n; Granularity 2 is interval-level verification: Based on the successful weave-level verification, further verification is made to confirm whether the weaveDigest within the specified checkpoint interval is consistent with all traceability records within that interval. The verification method is as follows: obtain all traceability records within the interval, sort them by record number seqNum, redivide the weave segments according to the preset segment length L, recalculate the indexDigest_i, segmentDigest_i, and interval weaveDigest of each Segment_i, and compare them with the weaveDigest stored in the checkpoint. Granularity 3 is record-level verification: For a single specified traceability record, verify whether the clientSignature and systemSignature of the record are valid, locate the weave segment to which the record belongs, recalculate the indexDigest_i and segmentDigest_i of the segment, and then combine the segmentDigest sequence of the interval to verify that the record does indeed participate in the weaveDigest generation of the checkpoint interval. The multi-granularity scaling verification in step S5 also includes selective interval jump verification, specifically including the following operations: c1: The auditor specifies the verification time range [verification start time T_start, verification end time T_end]. The system locates the start checkpoint W_start and end checkpoint W_end that cover this time range based on the timestamp of each checkpoint. c2: For checkpoints outside the entire verification scope, perform weave-level verification: verify only the consistency of their checkpointHash chain; for checkpoints within the verification scope, perform interval-level verification: verify the consistency of weaveDigest interval by interval; for specific access records of particular concern to the auditor within the verification scope, perform record-level verification: the verification content includes signature verification and weave segment digest verification.

[0010] A shared service link traceability management system includes: a link creation module, a concurrent traceability record generation module, a checkpoint weaving module, a dual signature generation module, a multi-granularity verification module, an archiving module, and a key evolution management module; The link creation module is used to receive link creation requests from clients, perform permission verification, create shared service links, and generate a founding weaving checkpoint W_0. The concurrent tracing record generation module is used to generate tracing records in parallel for concurrent data access requests within each weaving checkpoint interval; there is no prevHash dependency between tracing records within the same checkpoint interval, and it supports multi-threaded or multi-instance parallel processing. The checkpoint weaving module is used to perform checkpoint weaving operations when the checkpoint triggering conditions are met. The dual signature generation module is used to coordinate the generation of digital signatures between the client and the system: it receives the clientSignature generated by the client using its forward security evolution private key for the core fields of the traceability record and verifies its validity, and generates the systemSignature using the system traceability signature private key; The multi-granularity verification module is used to support traceability verification at three granularities: weaving level, interval level, and record level, as well as selective interval jump verification. The sealing module is used to perform a forced weaving operation to generate a termination weaving checkpoint W_term when the link lifecycle ends, calculate the chain state fingerprint chainStateFingerprint, generate a sealing certificate, and mark the link as "sealed". The key evolution management module is used to manage the forward security key evolution mechanism on the client and system sides. Specific operations include: triggering key evolution according to a preset period, generating a new time period private key seed through one-way hashing, calculating the corresponding time period public key, securely deleting the old time period private key, and recording the new time period public key in the epochPublicKeys field of the key period public key list of the current active weaving checkpoint.

[0011] Its further features are: The shared service link traceability management system also includes: a checkpoint window adaptive module and an archive audit module; The checkpoint window adaptive module is used to monitor the average access volume C_avg within the most recent K knitting checkpoint intervals and dynamically adjust the time window length of the next checkpoint interval based on the time window length adaptive adjustment method. The archive audit module is used to perform archiving processing on traceability chain data of links that have been sealed and have exceeded the preset archiving period, migrate the woven checkpoint sequence data and interval traceability record data from online storage to archive storage medium, and generate integrity verification codes for archive data packages; the archived traceability chain supports offline auditing; when the auditor holds the archive data package and the sealing certificate, it supports full verification in a completely offline environment.

[0012] This invention provides a shared service link tracing management method. Through a two-layer structure of "concurrent forked tracing records and triggered checkpoint weaving"—a weaving checkpoint sequence and an interval record layer—it achieves high-concurrency writing of tracing records while preserving the integrity of the cryptographic chain, resolving the fundamental technical contradiction between cryptographic chain dependency and high-concurrency processing. Within the same checkpoint interval, tracing records are independent of each other and have no prevHash dependency, thus allowing for parallel generation and writing. This significantly improves the concurrent generation capability of tracing records within the same checkpoint interval. The system's concurrency capability is mainly limited by computing resources, signature verification capabilities, storage writing capacity, and interval capacity threshold. At the checkpoint boundary, this scheme compresses the hash values ​​of all tracing records within the interval into a fixed-length weaveDigest through a segmented weaving method, and then embeds it into the checkpointHash of the weaving checkpoint sequence. This operation "folds" the parallelism within the interval into a node on a serial chain, ensuring the cryptographic integrity of the weaving checkpoint sequence while offloading the high-concurrency pressure from the weaving checkpoint sequence to the parallel space within the interval. In this method, the forward security key evolution mechanism generates private keys through one-way hash iteration and deletes old keys in real time. Simultaneously, the public key for each epoch is anchored to the weaving checkpoint sequence and protected by the prevCheckpointHash chain. This ensures that even if the current system key is leaked, attackers cannot reverse-engineer the historical private key, nor can they subsequently tamper with the historical public key already anchored in the weaving checkpoint sequence. Therefore, the authenticity of historical traceability records cannot be retroactively forged. In data compliance scenarios, this means that even if a security incident occurs, historical audit evidence remains valid and does not become invalid due to key leakage. This application uses a multi-granularity scalable verification mechanism, allowing auditors to flexibly choose the verification depth according to actual needs, achieving efficient auditing of the traceability chain. Routine inspections can perform only weaving-level verification; special audits can perform interval-level verification for specific time ranges; and during dispute evidence collection, record-level verification can be performed on specific records involved in the dispute. The on-demand combination of the three levels of verification avoids the computational waste of verifying the entire traceability chain for each audit. The technical solution of this application is suitable for data sharing scenarios that require tamper detection and traceability of high-concurrency shared data access but cannot deploy blockchain infrastructure. Attached Figure Description

[0013] Figure 1 This is a schematic diagram of the shared service link traceability management system in this invention; Figure 2 This is a schematic diagram of the "woven checkpoint sequence-interval record layer" two-layer structure in this invention; Figure 3 This is a schematic diagram illustrating the process of weaving traceability records into the weaving checkpoint sequence in the weaving checkpoint operation of this invention; Figure 4This is a schematic diagram illustrating the three granularities used in the multi-granularity scaling verification of this invention; Figure 5 This is a schematic diagram of the forward security key evolution mechanism in this invention; Figure 6 This diagram illustrates the effect of changes in the state of the weaving checkpoint sequence after the generation of traceability records and the execution of the checkpoint trigger weaving operation. Detailed Implementation

[0014] This invention includes a method for managing the traceability of shared service links, which includes the following steps.

[0015] S1: Build a shared service link traceability management system, and define the data structure of traceability records and the organization structure of traceability data in the system.

[0016] like Figure 1 As shown, the shared service link traceability management system constructed in this method includes: a link creation module, a concurrent traceability record generation module, a checkpoint weaving module, a dual signature generation module, a multi-granularity verification module, an archiving module, a key evolution management module, a checkpoint window adaptive module, and an archive auditing module. The data for weaving checkpoint sequences and interval record buffers is stored based on the traceability record storage module. The shared service link traceability management system enables traceability management of data from the target business system.

[0017] Link creation module: Receives link creation requests, performs permission verification, creates link metadata records, generates a generative tracing record P_0 and a generative weaving checkpoint W_0, writes the client's initial public key PK_0 and the system public key into the epochPublicKeys field of W_0, sets the linkId to W_0.checkpointHash and returns it to the client.

[0018] Concurrent source tracing record generation module: manages the record buffer for each active checkpoint interval; within each weaving checkpoint interval, it allocates a globally incrementing seqNum in parallel for concurrent data access requests and generates branched source tracing records; each source tracing record within the same checkpoint interval does not depend on the predecessor record, and there is no prevHash dependency between source tracing records, supporting multi-threaded / multi-instance parallel generation of source tracing records.

[0019] The checkpoint weaving module maintains a time window timer and record counter for each active checkpoint interval. When the time window expires or the number of records reaches N_max, a weaving operation is triggered, and the checkpoint weaving operation is executed. In a cluster deployment, distributed locks ensure that weaving operations on the same link are executed by only one instance at a time.

[0020] The dual-signature generation module manages the asynchronous interaction process of client signature requests and responses, coordinating the generation of digital signatures between the client and the system. It receives the clientSignature generated by the client using its forward security evolution private key for the core fields of the traceability record and verifies its validity. It then generates the systemSignature using the system's traceability signature private key. If the client signature times out, the access fails.

[0021] Multi-granularity verification module: Implements three verification granularities—weaving level, interval level, and record level—as well as selective interval jump verification; used to support traceability verification at these three granularities, as well as selective interval jump verification. Provides external verification interfaces and returns structured verification reports.

[0022] The sealing module listens for link lifecycle events. When a link's lifecycle ends, it performs a forced weaving operation, generates a termination weaving checkpoint W_term, calculates the chain state fingerprint chainStateFingerprint, generates a sealing certificate, and updates the link state, marking the link as "sealed". The entire sealing operation process is recorded in the audit log.

[0023] Key Evolution Management Module: This module manages the forward security key evolution mechanism for both the client and system sides. Specific operations include: triggering key evolution at preset intervals; receiving new public keys (epoch, PK_epoch) submitted by the client through a secure channel; generating new private key seeds for new time periods through one-way hashing; calculating the corresponding public key for the time period; securely deleting old private keys for the time period; and recording the triple (subjectId, epoch, PK_epoch) and the new public key for the time period in the epochPublicKeys field of the key period public key list for the currently active weaving checkpoint. During the next weaving, PK_epoch is anchored to the weaving checkpoint sequence. The system side manages private keys using the same mechanism.

[0024] The checkpoint window adaptive module maintains concurrent access statistics for the K most recent checkpoint intervals via a sliding window, monitors the average access volume C_avg within the K most recent woven checkpoint intervals, and dynamically adjusts the time window length for the next checkpoint interval based on an adaptive time window length adjustment method. When it is detected that T_window needs adjustment, a new T_window value is applied at the end of the current checkpoint interval.

[0025] Archive Audit Module: This module is used to perform archiving processing on traceability chain data that has been sealed and has exceeded the preset archiving period. It migrates the woven checkpoint sequence data and interval traceability record data from online storage to the archive storage medium and generates an integrity check code for the archive data package. The archived traceability chain supports offline auditing. When the auditor holds the archive data package and the sealing certificate, it supports full verification in a completely offline environment.

[0026] Specifically, the complete traceability chain data (woven checkpoint sequence + interval traceability record + woven segment summary data) of links that have been sealed for more than a preset archiving period (e.g., 180 days) is packaged into an archive file (e.g., Parquet columnar storage format), and after calculating the HASH integrity check code, it is migrated to low-cost object storage. The archive file, together with the sealing certificate, supports offline auditing—the auditor can recover the traceability chain from the archive file and perform full verification in an offline environment.

[0027] The data structure of the trace record (TraceRecord) defined in the system is shown in Table 1 below.

[0028] Table 1: Data Structure of Source Tracing Records

[0029] The data structure fields of the traceability record include: record sequence number seqNum, checkpoint sequence number cpSeq, access timestamp, access subject identifier clientId, operation type operationType, data scope fingerprint dataScopeFingerprint, access environment digest envDigest, key time period number epoch, client signature clientSignature, system signature systemSignature, and record hash value recordHash.

[0030] Among them, recordHash is the hash value calculated by concatenating all traceability record fields except for the recordHash field itself in a preset order; after the double signature is completed, the system calculates and writes the recordHash.

[0031] The key difference from traditional hash chains is that the tracing records in this application do not contain a `prevHash` field. `recordHash` is used to generate a segmented sequence weave digest for the client to hold as a tracing credential, and is not used to establish chain dependencies between records. The cryptographic associations between records are not implemented through individual `prevHash`s, but rather through a weave checkpointing mechanism at a higher checkpoint granularity.

[0032] In this application, the source records within the checkpoint interval are used to generate an interval summary (weaveDigest) through segmented weaving. Specifically, the steps include: s11: The system sorts all traceability records within the current weaving checkpoint interval in ascending order according to the record number seqNum, and divides them into several weaving segments Segment_i according to the preset segment length L. Each weaving segment contains a set of consecutive traceability records, with the first record numbered firstSeqNum and the last record numbered lastSeqNum.

[0033] s12: For each weaving segment, the system calculates the sequence number binding digest indexDigest_i; indexDigest_i performs hash calculation by concatenating the seqNum of each record in the segment with the recordHash in ascending order of seqNum, which is used to simultaneously bind the record set, record order, and the correspondence between the record sequence number and the record hash.

[0034] The segmentDigest_i for each weaving segment is calculated as follows: segmentDigest_i = HASH(segmentSeq || firstSeqNum || lastSeqNum || recordCount_i || indexDigest_i), where segmentSeq is the segment number and recordCount_i is the number of trace records contained in the segment.

[0035] s13: After obtaining the segmentDigest_i of all weaving segments, the system splices each segmentDigest_i in ascending order of segmentSeq and calculates the interval weaving digest: weaveDigest = HASH(cpSeq ||segmentCount || segmentDigest_1 || segmentDigest_2 || … || segmentDigest_m), where segmentCount is the number of weaving segments in the current checkpoint interval, and m is the total number of weaving segments.

[0036] s14: Write the weaveDigest to the weave checkpoint and participate in the calculation of checkpointHash: checkpointHash = HASH(cpSeq || cpTimestamp || weaveDigest || recordCount ||prevCheckpointHash || epochPublicKeys).

[0037] Through the above segmented weaving method, traceability records within the same checkpoint interval can still be generated in parallel. During the weaving stage, the system can compress all traceability records within the interval into a fixed-length weaveDigest, and bind the digest indexDigest_i by the sequence number to ensure the integrity of the record set, the consistency of the order, and that the sequence number correspondence cannot be tampered with.

[0038] The data structure definition for WeaveCheckpoint is shown in Table 2 below.

[0039] Table 2: Data Structure of Weaving Checkpoints

[0040] The checkpoint hash field corresponding to the regular checkpoint W_k and the terminating checkpoint W_term differs slightly. See below for details: For a regular checkpoint W_k (k≠term): checkpointHash = HASH(cpSeq || cpTimestamp || weaveDigest || recordCount || prevCheckpointHash || epochPublicKeys); For the terminating checkpoint W_term: checkpointHash = HASH(cpSeq || cpTimestamp ||weaveDigest || recordCount || prevCheckpointHash || epochPublicKeys ||chainStateFingerprint).

[0041] The `epochPublicKeys` field, which lists the public keys for each key period, participates in the calculation of the checkpoint hash. This ensures that once a recorded key period is woven into the checkpoint sequence, it is protected by the one-way integrity of the `prevCheckpointHash` chain and cannot be tampered with afterward. The `chainStateFingerprint` field exists only in the terminating checkpoint `W_term` and is used to provide a cryptographic commitment to the entire historical checkpoint state of the checkpoint sequence during sealing.

[0042] The traceability data is organized in a two-layer structure based on a weave checkpoint sequence and an interval record layer. The weave checkpoint sequence is formed by unidirectionally linking weave checkpoints in chronological order. Each weave checkpoint contains an interval summary (weaveDigest) generated by segmenting and weaving all traceability records generated within that checkpoint interval. The interval record layer is temporarily composed of multiple traceability records generated concurrently within the same checkpoint interval. There is no prevHash dependency between the traceability records within the interval record layer, allowing for parallel generation.

[0043] The organizational structure of the traceability data defined in this method is as follows: Figure 2 As shown. The weaving checkpoint sequence in the traceability chain includes: the sequentially connected founding weaving checkpoint W_0, ordinary weaving checkpoints W_1, ..., ordinary weaving checkpoints W_n, and the termination checkpoint W_term (not marked in the figure) located at the end.

[0044] Each checkpoint W_K corresponds to an interval record layer, forming the checkpoint interval K. The sequence number of each checkpoint interval is the same as the sequence number cpSeq of its corresponding checkpoint; that is, the checkpoint interval corresponding to checkpoint W_0 is interval 0, and the checkpoint interval corresponding to checkpoint W_1 is interval 1.

[0045] Within each checkpoint interval, the record sequence number (seqNum) is assigned according to the arrival time of the request. All records are then sorted by their seqNum sequence number to obtain the source record set P_K included in the checkpoint interval. Source records within the same checkpoint interval are arranged in ascending order by their seqNum sequence number, and after being segmented and woven into a weaveDigest, they are embedded into the corresponding checkpoint. Similarly, from interval 0 corresponding to checkpoint W_0 to interval term corresponding to W_term, the record sequence numbers of all source records included in all checkpoint intervals also form an ascending order queue. For example... Figure 2 In this system, interval 0 includes the source record P_0, interval 1 includes source records P_1 to P_4, and interval n includes source records P_i, ..., P_k. The record numbers of all source records form a complete ascending sequence {P_0, P_1, P_2, P_3, P_4, ..., P_i, ..., P_k}, and subsequent source records continue in the same ascending order. Source records within the same interval have no prevHash dependency and can be generated in parallel. The checkpoint sequence is woven using a one-way link via prevCheckpointHash to ensure global cryptographic integrity.

[0046] The link relationship between weave checkpoints is: W_k.prevCheckpointHash = W_{k-1}.checkpointHash. This structure is similar to the blockchain connection of a blockchain, but the essential difference is that: (1) The records in the weave checkpoint are not a hash chain structure, but a segmented sequence of weave digests (instead of the linear transaction list of the blockchain) generated after the seqNum determines the order, allowing records to be generated in parallel; (2) The time window of the weave checkpoint is adaptive (instead of the fixed block time of the blockchain), and is dynamically adjusted according to the concurrency; (3) The epochPublicKeys field of the weave checkpoint additionally assumes the anchoring responsibility of the key evolution public key, providing weave checkpoint sequence-level integrity protection for the forward security key evolution mechanism.

[0047] In the traceability chain constructed in this application, the weave checkpoint sequence adopts a hash chain structure, which has the ability to detect tampering, but the number of weave checkpoints in the weave checkpoint sequence is smaller; the interval record layers in each checkpoint interval of the weave checkpoint sequence are serially related, and the subsequent interval record layer will only be activated when the previous interval record layer is closed, with only one active checkpoint interval at a time. However, the traceability records within the same active checkpoint interval are parallel to each other and can be written simultaneously.

[0048] In step S1, the time window length T_window of the checkpoint interval is an adaptive parameter, and the adaptive adjustment method of the time window length includes the following.

[0049] s11: Define the average access count C_avg as the ratio of the sum of the number of records in the most recent K intervals to the sum of the time spans: C_avg = (sum of recordCounts of the K most recent intervals) / (sum of actual time spans of the K most recent intervals); The value of K is set according to actual needs. In this embodiment, K=10 is set.

[0050] s12: The system monitors the average access volume C_avg within the interval of the most recent K knitting checkpoints; When C_avg exceeds the preset high concurrency threshold C_high, T_window is shortened; when C_avg is below the preset low concurrency threshold C_low, T_window is extended. T_window is between the preset lower limit T_min and the upper limit T_max.

[0051] The specific high-concurrency thresholds C_high and C_low are adaptively set based on the system's hardware performance and processing volume. In this embodiment, the high-concurrency thresholds C_high = 1000 times / second and C_low = 100 times / second.

[0052] Specifically, if C_avg > 1000 times / second, the T_window is shortened to half its current value (not less than T_min = 100ms), making checkpoint weaving more frequent, reducing the number of records per interval, and making the weave segment size and weaveDigest verification overhead more controllable; if C_avg < 100 times / second, the T_window is extended to twice its current value (not exceeding T_max = 5000ms), reducing the weaving frequency, slowing the growth of the number of weave checkpoint sequences, and saving storage. This adaptive mechanism allows the weaving rhythm to automatically match the actual concurrent load.

[0053] The adaptive time window method constructed in this application shortens the window when access requests are under high concurrency, resulting in more frequent weaving, fewer records per interval, and more controllable weaving segment size and weaveDigest verification overhead. When concurrency is low, the window time is extended, reducing weaving operations and slowing the growth rate of the weaving checkpoint sequence, thus saving storage. The effect of this design is that the construction of checkpoint and interval record layers automatically adjusts according to the system load and concurrent event traffic, ensuring the system can respond quickly during periods of high concurrency, while saving resources during periods of low concurrency.

[0054] S2: When a client needs to create a shared service link, it submits a link creation request to the shared service link traceability management system.

[0055] The link creation request includes: client identity credentials, target business resource identifier resourceId, requested operation type and data range, link validity period and maximum access limit.

[0056] After the system verifies and approves the client's permissions, it creates a link and generates the initial weaving checkpoint W_0; The founding weaving checkpoint W_0 contains the following fields: checkpoint sequence number cpSeq=0, checkpoint closing timestamp cpTimestamp, the unique founding trace record P_0 of this checkpoint W_0 generated by segmented weaving of the interval digest weaveDigest, record count=1, previous checkpoint hash prevCheckpointHash, key period public key list epochPublicKeys, and checkpoint hash value checkpointHash; Among them, checkpointHash = HASH(cpSeq || cpTimestamp || weaveDigest ||recordCount || prevCheckpointHash ||epochPublicKeys); The hash of the previous checkpoint corresponding to the founding checkpoint W_0, prevCheckpointHash, is a 32-byte all-zero value. The public key list epochPublicKeys for the key period adopts a unified triple list format, with each item being (subjectId, epoch, publicKey); the epochPublicKeys in the founding weaving checkpoint W_0 includes (clientId, epoch=0, PK_client) and (systemId, 0, PK_system); Set the link identifier (linkId) to the checkpointHash value of the initial weaving checkpoint W_0, thus cryptographically binding the link identifier to the initial state of the traceability chain and achieving a one-to-one cryptographic correspondence between the link identifier and the traceability chain.

[0057] The founding checkpoint W_0 contains only one founding trace record P_0 (operationType=0x00 LINK_CREATE). The generation process of W_0 is as follows: s21: Generate the origin trace record P_0: seqNum=0, cpSeq=0, record the meta-information when the link was created; s22: Generate a segmented sequence weave digest of the originating checkpoint interval using the recordHash of P_0; when the interval contains only P_0, the record constitutes a unique weave segment Segment_1, and an interval digest is generated according to the calculation rules of segmentDigest_1 and weaveDigest. s23: Write the client's initial public key and the system public key into the epochPublicKeys field as triples of (clientId, epoch=0, PK_client) and (systemId, 0, PK_system), respectively; s24: Calculate W_0.checkpointHash = HASH(0 || cpTimestamp || weaveDigest ||1 || 0x000…000 || epochPublicKeys), where prevCheckpointHash is a 32-byte all-zero value; s25: linkId = W_0.checkpointHash.

[0058] Setting `linkId` as the origin checkpoint hash has the following effects: First, any attempt to replace the entire origin chain of this link with another origin chain will be detected because "linkId ≠ W_0.checkpointHash of the replaced origin chain"; Second, due to the collision resistance of hash functions, attackers cannot computationally construct another different origin checkpoint W_0' such that W_0'.checkpointHash = linkId; Third, due to the unidirectional linking relationship of the weaving checkpoint sequence's `prevCheckpointHash`, the W_0 uniquely determined by `linkId` also uniquely determines the evolutionary trajectory of all subsequent legitimate weaving checkpoint sequences. Thus, a cryptographic one-to-one correspondence is established between `linkId` and the origin chain.

[0059] In this application, both the client and system's signature private keys are managed using a forward-secure key evolution mechanism. This mechanism divides time into independent key time periods. At the beginning of each key time period, the private key is evolved using a one-way hash function, and then the old private key is immediately deleted. Therefore, even if the new private key is stolen, an attacker cannot obtain the old private key. Figure 5 As shown, the forward security key evolution mechanism is explained using the client as an example.

[0060] The forward security key evolution mechanism specifically includes the following steps.

[0061] b1: Divide the entire lifecycle of the system into several key periods, each key period corresponding to a unique period number epoch; the duration of each period is a preset value, and in this embodiment, a key period is set to 24 hours.

[0062] b2: When registering for the first time, the client generates an initial key pair (SK_0, PK_0) using a signature key generation algorithm, where SK_0 is a random integer within the range of legal private key values ​​specified by the signature algorithm, and n is the order of the signature recommendation curve; PK_0 = SK_0 · G, where G is the base point of the signature elliptic curve; PK_0 is stored in the client certificate of the system after being signed by the CA, and serves as the trust anchor point of the client's public key chain.

[0063] b3: Subsequently, at each new key period, the client performs the following key evolution operation: b31: The new private key for the current time period is obtained by iterating over the current private key using the HASH one-way hash function and modulo n: SK_epoch = HASH(SK_{epoch-1}) mod n; If the result is 0 or n-1, then HASH(SK_{epoch-1} || 0x01) mod n is used to recalculate, to ensure that the new private key falls within the range [1, n-2] of the valid private key for signing; Figure 5 In this example, the new private key SK_new = SM3 (the old private key SK_old); b32: Calculate the public key for the corresponding time period: PK_epoch = SK_epoch·G; b33: Submit the tuple (epoch, PK_epoch) to the system through the established secure channel between the client and the system; b34: The system records the triple (clientId, epoch, PK_epoch) in the epochPublicKeys field of the currently active checkpoint, so that when the checkpoint is closed and participates in the weaving of the checkpoint sequence, PK_epoch is cryptographically anchored to the weaving checkpoint sequence. b35: The client overwrites and deletes SK_{epoch-1} in the client's secure storage area (such as a TEE trusted execution environment or a secure enclave), retaining only SK_epoch for the traceability record signature of the current time period.

[0064] b4: In each traceability record, the client signature clientSignature is signed using the private key SK_epoch corresponding to the key period in which the record was generated, and the key period used for signing is marked in the traceability record by the epoch field.

[0065] b5: During subsequent audit verification of clientSignature, the verifier reads PK_epoch from the epochPublicKeys field of the weaving checkpoint that records the epoch public key in the weaving checkpoint sequence based on the epoch field in the traceability record, and uses PK_epoch to perform signature verification of clientSignature.

[0066] Specifically, during the audit verification phase, the verification process for clientSignature is as follows.

[0067] b51: Read the epoch field from the trace record to be verified, denoted as e, and read the clientId, cpSeq, clientSignature, and other fields in the record.

[0068] b52: Based on the cpSeq field in the traceability record, locate the weaving checkpoint W_cp to which the record belongs along the weaving checkpoint sequence; at the same time, based on clientId and epoch=e, find the corresponding public key record triple (clientId, e, PK_e) in the epochPublicKeys field of each weaving checkpoint in the weaving checkpoint sequence, and locate the weaving checkpoint W_pk that records the public key.

[0069] b53: Before using PK_e, the verifier must first confirm the validity of the weave-level verification result of the weave checkpoint sequence segment where W_pk is located. Weave-level verification refers to verifying whether the checkpointHash of W_pk is equal to the hash value recalculated from its constituent fields, and verifying whether the prevCheckpointHash of adjacent checkpoints from W_pk to the current latest checkpoint is consistent with the checkpointHash of the previous checkpoint. If the system has saved the previous trusted verification result, the verifier can perform incremental verification from the previously verified checkpoint, without having to perform a full verification starting from the founding checkpoint W_0 each time.

[0070] If the above weaving-level verification passes, it indicates that W_pk has not been tampered with, and the epochPublicKeys field in W_pk has been continuously anchored through the prevCheckpointHash chain structure of subsequent checkpoints. Since the epochPublicKeys field participates in the calculation of W_pk.checkpointHash, any replacement, deletion, or addition of PK_e within it will cause the verification of W_pk.checkpointHash or subsequent chain relationships to fail. Therefore, the PK_e read from W_pk.epochPublicKeys can be used as a cryptographically trusted client public key.

[0071] b54: The verifier uses PK_e to perform a signature verification algorithm on clientSignature to verify whether the signature was generated by the client holding the private key SK_e for the corresponding time period. SK_e is obtained by one-way hashing the private key of the previous time period, i.e., SK_e = HASH(SK_{e-1}) mod n.

[0072] The verification of systemSignature adopts the same public key positioning and chained trust confirmation process. The difference is that when querying epochPublicKeys, subjectId takes the system subject identifier systemId instead of the client identity identifier clientId, that is, the triple searched in step b52 is (systemId, e, PK_e). The above verification process does not require the verifier to hold any private key. The verifier only needs to trust the CA authentication result of the client's initial public key PK_0, the trusted source of the system public key, and the chained consistency of the woven checkpoint sequence checkpointHash, then can verify clientSignature and systemSignature for any epoch period.

[0073] The security proof of the forward secure key evolution mechanism is as follows: suppose an attacker obtains the current private key SK_t in epoch=t, and attempts to forge a clientSignature on a historical traceability record of epoch=s (s<t). The attacker has two attack paths, both of which are infeasible, and the reasons are as follows.

[0074] Path 1 is reverse derivation of historical private key: since the relationship between SK_s and SK_t is SK_t = HASH {t-s} (SK_s) mod n, the attacker needs to reversely solve SK_s from SK_t. Since HASH is a one-way hash function, under standard cryptographic assumptions, finding the pre-image of a one-way hash function is computationally infeasible, given SK_epoch, the attacker cannot computationally reverse derive SK_{epoch-1}. Meanwhile, SK_s has been securely deleted when epoch=s+1 is enabled, so the attacker cannot obtain SK_s per se, and thus cannot generate a legal signature.

[0075] Path two involves forging public key records for impersonation: An attacker attempts to forge a traceability record with epoch=s using a self-generated key pair (SK'_s, PK'_s), and tries to get the verifier to accept PK_s as a legitimate public key for epoch=s. However, the legitimate public key PK_s corresponding to epoch=s has already been recorded in the epochPublicKeys field of a historical weaving checkpoint W_pk, and W_pk.checkpointHash is anchored through the prevCheckpointHash chain of all subsequent checkpoints in the weaving checkpoint sequence. The attacker cannot subsequently tamper with the public key already recorded in the historical checkpoint. If the attacker wants to replace PK_s with PK'_s, they must recalculate the checkpointHash of W_pk and all subsequent checkpoints, which is equivalent to forging the entire weaving checkpoint sequence, and will be immediately detected by weaving-level verification (granularity one).

[0076] In summary, under the three standard cryptographic assumptions of one-way hashing, unforgeable signatures, and the integrity of the prevCheckpointHash chain, the forward secure key evolution mechanism guarantees that the clientSignature of historical traceability records remains unforgeable even after the current private key is compromised. Attackers cannot forge any legitimate clientSignature with an epoch shorter than the current one, and the unforgeability of historical traceability records remains valid even after the current private key is compromised.

[0077] S3: The system returns the generated shared service link to the client; The access address for the shared service link is: https: / / {system domain name} / api / traceable-link / {linkId}. Here, linkId is a hexadecimal string representing W_0.checkpointHash.

[0078] S4: When a client initiates a data access request through a shared service link, the system performs concurrent branched tracing record generation and checkpoint trigger weaving operations, specifically including the following steps.

[0079] a1: Extract the link identifier (linkId) from the shared service link to locate the source chain corresponding to the link and its current active range; An active range refers to a checkpoint range that is currently receiving new traceability records and has not yet been closed; there is only one active range for the same traceability chain at any given time.

[0080] a2: Check if the current active zone can still receive new records; detection methods include: Confirmation Time: Confirm that the time window for the current active period has expired. If it has expired, new records cannot be accepted; otherwise, new records can be accepted. Confirm capacity: Confirm that the cumulative number of traceable records within the current active range has reached the threshold N_max. If the threshold has been reached, new records cannot be accepted; otherwise, new records can be accepted. If the current active interval cannot accept new records, first perform the weaving checkpoint operation in step a3 to close the current active interval and create a new active interval. Then, use the newly created active interval as the current active interval and perform steps a4 to a6. If the current active range can still accept new records, proceed directly to steps a4~a6.

[0081] a3: The specific process of weaving checkpoint operations is as follows: Figure 3 As shown.

[0082] In this application, the knitting checkpoint operation is triggered by three preset checkpoint trigger conditions, and the knitting checkpoint operation is started when any one of them is met.

[0083] Triggering condition 1: The time window for the current active period has expired; Triggering condition 2: The cumulative number of traceability records in the current active range has reached the threshold N_max (e.g., N_max=10000). Triggering condition three: The system receives a manual instruction to trigger the weaving process; If any one of the conditions is met, the weaving checkpoint operation is triggered.

[0084] The trigger condition detection performed in step a2 is a detection performed on trigger condition one and trigger condition two.

[0085] Once the triggering conditions are met, the checkpoint weaving operation includes the following steps: a31: Lock the record buffer of the current checkpoint interval, stop writing new records, and queue new requests; sort the hash values ​​of all trace records in the current checkpoint interval in ascending order according to the record number seqNum to obtain the sorted recordHash sequence. In high-concurrency write scenarios, before allocating seqNum for an access request and writing it to the active range, the system should pre-allocate the range capacity using an atomic counter, distributed lock, or compare-and-swap mechanism. If the pre-allocation exceeds N_max, the request should not be written to the original active range but should wait for the creation of a new active range before writing.

[0086] a32: The system divides the sorted source records into several segments Segment_i according to a preset segment length L, and calculates the sequence number-bound digest indexDigest_i. The calculation method for indexDigest_i is as follows: First, the seqNum of each record in the Segment_i is concatenated with the recordHash to obtain a concatenation pair. Then, all concatenation pairs in the segment are concatenated together in ascending order of seqNum and hashed to obtain indexDigest_i. indexDigest_i is used to bind the record set, record order, and the correspondence between record number and record hash at the same time. This method calculates the segmentDigest_i for each weaving segment, covering the segment number, first and last sequence numbers, and sequence number binding digest. The specific calculation method for segmentDigest_i is as follows: segmentDigest_i = HASH(segmentSeq || firstSeqNum || lastSeqNum || recordCount_i || indexDigest_i); The system concatenates each segmentDigest_i in ascending order of segmentSeq and calculates weaveDigest = HASH(cpSeq || segmentCount || segmentDigest_1 || segmentDigest_2 || … || segmentDigest_m); Get the checkpointHash of the previous weaving checkpoint as the prevCheckpointHash; Collect the newly enabled key period public keys (if any) within this checkpoint interval, and assemble the epochPublicKeys field; After obtaining the segmentDigest_i of all weaving segments, the system splices each segmentDigest_i in ascending order of segmentSeq and calculates the interval weaveDigest, and then executes step a33. a33: Calculate the checkpoint hash value of the current weave checkpoint: checkpointHash = HASH(cpSeq ||cpTimestamp || weaveDigest || recordCount || prevCheckpointHash||epochPublicKeys); Where, prevCheckpointHash is the checkpointHash of the previous weaving checkpoint; a34: Append the current knitting checkpoint to the end of the knitting checkpoint sequence; W_k is written to persistent storage, and the transaction is committed. a35: Open a new active range: cpSeq+1, reset the time window, clear the record buffer, initialize empty weave segment cache and range weave summary state. Release locks and process queued access requests.

[0087] The weaving operation is completed within a database transaction, ensuring atomicity; if the system restarts abnormally during the weaving process, consistency can be restored by re-executing the weaving operation.

[0088] a4: Within the current active checkpoint interval, generate a source record for this access; the generation of the source record is independent of the generation of source records for other concurrent accesses within the same checkpoint interval, with no prevHash dependency, and each source record supports parallel generation.

[0089] a5: After each traceability record is generated, perform the following operations sequentially on the generated record. The dual-signature process, involving both client-side and system-side signatures, is performed as follows: a51 dual signature: First, the accessing client uses its current key period private key SK_epoch to sign the core field and generate clientSignature; after the system verifies the validity of clientSignature, it uses the system traceability signing private key to sign (core field || clientSignature) and generate systemSignature. a52 Record Hash Calculation: After the double signature is completed, the system will concatenate the traceability record fields other than the recordHash field itself in a preset order and calculate the recordHash; subsequent writes to the buffer and weaving digest inputs will be based on this recordHash.

[0090] The core fields include: seqNum, cpSeq, timestamp, clientId, operationType, dataScopeFingerprint, envDigest, and epoch; among which clientId is the identifier of the access subject corresponding to this access request, which is not necessarily the same as the identifier of the creator of the shared service link.

[0091] a53 Write Buffer: After the signature and recordHash calculations are completed, the traceability record and its seqNum and recordHash are written to the record buffer of the active region for the generation of weaveDigest when the checkpoint is closed; a54 Returns Source Credentials: Returns the source credentials for this access to the client. The source credentials include: the record hash value of this source tracing record and the current record sequence number seqNum; a56 Capacity Check: After writing is complete, if the cumulative number of records in the active region has reached N_max, an a3 weaving operation is immediately triggered to create a brand new active region.

[0092] a6: Request forwarding: According to the routing rules corresponding to the shared service link, forward this data access request to the target business system. When forwarding, attach the source identification (linkId and seqNum of this access) so that the business system can associate the source record in its own log.

[0093] After the traceability record generation and checkpoint triggering weaving operation are executed, the state change effect of the weaving checkpoint sequence is as follows: Figure 6 As shown. In the active interval following the weaving checkpoint W_{k-1}, after accumulating enough traceability records or the time window of the active interval has expired, a new checkpoint W_k is generated, and a new active interval continues to be opened after checkpoint W_k: cpSeq=k+1. Through the traceability chain structure designed in this application, the parallel traceability record data within the active checkpoint interval is compressed into a fixed-length weaveDigest through segmented weaving and written into a checkpoint in the weaving checkpoint sequence. Compared with the existing serial form of blockchain, the growth rate of the weaving checkpoint sequence is reduced from once per weaving record to once per checkpoint interval, which can significantly reduce the storage and verification overhead for the system. At the same time, the cryptographic integrity of the weaving checkpoint sequence can still be guaranteed based on the prevCheckpointHash unidirectional chain.

[0094] S5: When it is necessary to trace and audit the access history of a shared service link, multi-granularity scalable verification supports the auditor to select the verification depth according to actual needs.

[0095] like Figure 4 As shown, multi-granularity scaling verification includes the following.

[0096] Granularity 1 is the weaving-level verification: it only verifies the chain consistency of checkpointHash of each weaving checkpoint in the weaving checkpoint sequence, that is, it verifies whether the prevCheckpointHash of each checkpoint is equal to the checkpointHash of the previous checkpoint, and verifies whether the checkpointHash of each checkpoint is equal to the HASH hash calculation result of its constituent fields; the time complexity of weaving-level verification is O(m), where m is the number of weaving checkpoints, and m is much smaller than the total number of accesses n.

[0097] Weave-level verification performs coarse-grained inspections of each weave checkpoint in the weave checkpoint sequence, starting from W_0, and verifies in sequence: (1) W_k.prevCheckpointHash equals W_{k-1}.checkpointHash (chain consistency); (2) W_k.checkpointHash equals HASH(cpSeq || cpTimestamp || weaveDigest || recordCount || prevCheckpointHash || epochPublicKeys) (self-consistency).

[0098] From W_0 to W_term, a checkpointHash chain-based consistency verification is performed. The complexity of the weave-level verification is O(m), where m is the number of weave checkpoints. Since m is much smaller than the total number of accesses n (one weave covers hundreds to thousands of accesses), this verification granularity can significantly reduce computational overhead compared to record-by-record verification, making it suitable for routine automated inspections.

[0099] Granularity 2 is interval-level verification: Interval-level verification corresponds to medium-granularity special audits. Based on the successful completion of the weaving-level verification, the following verification is performed on specific checkpoint intervals of interest to the auditor: Verify whether the weaveDigest within a specified checkpoint interval is consistent with all traceability records within that interval. The verification method is as follows: obtain all traceability records within the interval, sort them by record sequence number seqNum, redivide the weave into segments according to a preset segment length L, recalculate the indexDigest_i, segmentDigest_i, and interval weaveDigest for each segment_i, and compare them with the weaveDigest stored in the checkpoint. If they are consistent, it proves that the record set within the interval is complete, the order is consistent, and the sequence number correspondence has not been tampered with.

[0100] like Figure 4The assumption shown is that interval-level verification is performed only for the interval k corresponding to checkpoint W_k. Assuming that the records included in interval k are P_k0, P_k1, P_k2, ..., then P_k0, P_k1, P_k2, ... are sorted and divided into weaving segments according to the record number seqNum. The segmentDigest_i and weaveDigest are recalculated, and the value of weaveDigest is compared with the weaveDigest of the record in checkpoint W_K. If the two are consistent, the verification is successful.

[0101] Granularity 3 is record-level verification. For a single specified traceability record, it verifies whether the clientSignature and systemSignature of the record are valid, locates the weave segment to which the record belongs, recalculates the indexDigest_i and segmentDigest_i of the segment, and then verifies that the record does indeed participate in the weaveDigest generation of the checkpoint interval by combining the segmentDigest sequence of the interval.

[0102] Weave-level verification can be used for routine inspections, interval-level verification can be used for special audits, and record-level verification is used for evidence collection in fine-grained disputes. Triple verification is performed on a single specified traceability record.

[0103] Specifically, such as Figure 4 As shown, assume the record to be verified is: target record P_j, (1) Verify the validity of clientSignature for target record P_j: obtain PK_epoch from the woven checkpoint sequence epochPublicKeys according to the method of steps b51~b54, and use PK_epoch to verify the signature. (2) Verify the validity of systemSignature for target record P_j: Verify the signature using the system management public key; (3) Weave segment digest verification: For the target record P_j, calculate its corresponding record hash value recordHash_j; during verification, locate the weave segment Segment_i to which the record belongs, obtain all traceable records in the weave segment, and recalculate indexDigest_i' and segmentDigest_i' in ascending order of seqNum; then recalculate weaveDigest' by combining all segmentDigest_i sequences in the checkpoint interval where the target record is located. Read the original weaveDigest from the checkpoint storage data of the target record P_j, and compare weaveDigest' and weaveDigest. If they match, it means that the target record P_j has participated in the generation of the weaveDigest of its respective checkpoint interval, and recordHash_j has been bound to the corresponding indexDigest_i, and the record-level verification of the target record P_j passes. If they do not match, the record-level verification of the target record P_j fails. The materials required for record-level verification include: the target traceability record, all traceability records or digest proofs within the weave segment where the target record is located, the segmentDigest_i sequence of the respective checkpoint interval, the respective weave checkpoint, and the relevant epochPublicKeys.

[0104] Multi-granularity scaling validation also includes selective interval jump validation; specifically, it includes the following operations: c1: The auditor specifies the verification time range [verification start time T_start, verification end time T_end]. The system locates the start checkpoint W_start and end checkpoint W_end that cover this time range based on the timestamp of each checkpoint. c2: Perform weaving-level verification for checkpoints outside the entire verification scope: only verify the consistency of their checkpointHash chain, that is: for W_0 to W_{start-1} and W_{end+1} to W_term, only perform weaving-level verification (O(m)). For checkpoints within the verification scope, i.e., all traceable records within the interval from W_start to W_end, interval-level verification is performed: verifying the consistency of weaveDigest interval by interval; for specific access records of particular concern to the auditor within the verification scope, record-level verification is performed: the verification content includes signature verification and weave segment digest verification. The total verification time complexity is O(m + k·s + r·s_r), where m is the total number of checkpoints, k is the number of checkpoints involved in interval-level verification, s is the weave segment and record recalculation cost within the interval, r is the number of records for record-level verification, and s_r is the recalculation cost of the weave segment containing a single record.

[0105] S6: When the lifecycle of a shared service link ends, the system performs a traceability chain sealing operation; The lifecycle of a shared service link is determined to have ended if any of the following conditions are met. The link is valid until the validity period expires (validityPeriod.until), the maximum number of accesses (maxAccessCount) is reached, or it is manually revoked by the administrator. The validity period (validityPeriod.until) and the maximum number of accesses (maxAccessCount) are preset values; the specific values ​​should be set according to the actual system requirements.

[0106] The sealing operation includes the following: s61: First, a forced weaving checkpoint operation is performed. The checkpoint interval at the end of the weaving checkpoint sequence is the currently active checkpoint interval. All traceability records within the currently active checkpoint interval are woven into a termination weaving checkpoint W_term. The difference between W_term and a normal weaving checkpoint is that the termination weaving checkpoint W_term additionally contains a chain state fingerprint chainStateFingerprint, which is calculated as follows: chainStateFingerprint = HASH(W_0.checkpointHash || W_1.checkpointHash|| ... || W_{term-1}.checkpointHash); The checkpointHash sequence of all weaving checkpoints before the terminating weaving checkpoint W_term is concatenated in ascending order by checkpoint number cpSeq and then hashed.

[0107] The formula for calculating the checkpoint hash value of the terminating weaving checkpoint W_term is expanded accordingly to: W_term.checkpointHash = HASH(cpSeq || cpTimestamp || weaveDigest || recordCount || prevCheckpointHash || epochPublicKeys || chainStateFingerprint); The introduction of the `chainStateFingerprint` field allows `W_term.checkpointHash` to simultaneously carry both a "commitment to all traceable records within the last checkpoint interval" (via `weaveDigest`) and a "commitment to all historical checkpoints in the weaving checkpoint sequence" (via `chainStateFingerprint`). Any subsequent tampering with any checkpoint in the weaving checkpoint sequence will cause the recalculated `chainStateFingerprint` to differ from the `chainStateFingerprint` stored in the sealed certificate, thus being immediately detected by the auditor during offline verification.

[0108] Once the sealing is complete, a sealing certificate is generated, the link is marked as sealed, and any new access requests and appending of traceability records are rejected.

[0109] The sealing certificate consists of the following fields: linkId, sealing timestamp (sealTimestamp), totalCheckpoints (totalCheckpoints), totalRecords (totalRecords), chainStateFingerprint (chainStateFingerprint), sealing reason (sealReason), and a signature (sealSignature) on all the above fields. The signature calculation formula is: sealSignature = Sign(systemKey, linkId ||sealTimestamp || totalCheckpoints || totalRecords || chainStateFingerprint ||sealReason). The sealing certificate can be stored offline and can be retrieved and verified by regulatory agencies or auditors at any time. After sealing, the link status is updated to "SEALED". Afterward, any access request carrying this linkId will return HTTP 410 Gone, and any attempt to append new records or checkpoints to this link will be rejected.

[0110] This application's solution can be applied to various scenarios, setting up a traceability chain based on the subject requiring traceability in each scenario. For example, when applying this solution to a driver's license management system for motor vehicles or electric bicycles, a traceability chain can be constructed for each shared service link, each logged-in user, or each business object, depending on the scenario. At any given time, each traceability subject has only one active traceability chain. All traceable content in the driver's license management system is set as a traceability record type. For example, each update of user data corresponds to a separate traceability record; similarly, each user operation in the system, such as login, retrieval, and data entry, corresponds to a separate traceability record. If multiple traceability records are generated simultaneously within the same time interval (e.g., 1 second) due to user operations and data modifications in the system backend, these records will be processed concurrently and written to the currently active checkpoint interval. This is more efficient than the existing serial writing method. Furthermore, managing these traceability records through a single interval record layer corresponds to only one checkpoint in the woven checkpoint sequence. When this interval recording layer is closed due to time expiration or the number of records reaching the maximum value, all traceability records in the interval recording layer are segmented, woven, compressed into a weaveDigest, and written to the checkpoint, effectively improving security.

[0111] The lifecycle termination conditions for the traceability chain, including link expiration and link access count, are adaptively set based on actual data changes in the system. For example, from a practical application perspective, data from 5 years ago is rarely accessed, so the link expiration period is set to 5 years. To avoid an excessively large traceability chain impacting retrieval efficiency, if retrieval efficiency significantly decreases when the traceability chain includes nearly 10,000 records based on system hardware performance, the maximum number of link accesses can be set to 10,000. Once the lifecycle termination conditions for the traceability chain are met, the current traceability chain is archived, and a new traceability chain is generated.

[0112] By employing the technical solution of this invention, the system supports high-concurrency access traceability while preserving cryptographic integrity through a two-layer structure of "concurrent forking-periodic weaving"—a weaving checkpoint sequence and an interval record layer. In a typical configuration with a 1-second weaving cycle and each weave containing 1000 fork traceability records, the checkpoint growth rate of the weaving checkpoint sequence is only 1 per second (instead of 1000), significantly reducing the overhead of weaving checkpoint sequence storage and weaving-level verification. The forward-secure key evolution mechanism generates private keys through one-way hash iteration and immediately deletes old keys, while simultaneously anchoring the public key of each epoch to the weaving checkpoint sequence, protected by the prevCheckpointHash chain. This ensures that even if key leakage occurs, the authenticity of historical traceability records remains unforgeable. Multi-granularity scalable verification allows for varying verification depths for routine inspections, special audits, and dispute evidence collection. This solution requires no blockchain infrastructure, is simple to deploy, and is suitable for data sharing scenarios that require tamper-proof traceability of high-concurrency shared data access but are limited by budget and technical constraints.

Claims

1. A method for tracing and managing shared service links, characterized in that, It includes the following steps: S1: Build a shared service link traceability management system, and define the data structure of traceability records and the organization structure of traceability data in the system; The data structure of the traceability record includes the following fields: record sequence number seqNum, checkpoint sequence number cpSeq, access timestamp, access subject identifier clientId, operation type operationType, data scope fingerprint dataScopeFingerprint, access environment digest envDigest, key time period number epoch, client signature clientSignature, system signature systemSignature, and record hash value recordHash. The traceability data is organized in a two-layer structure based on a woven checkpoint sequence and an interval record layer. The weave checkpoint sequence is formed by a unidirectional linking of weave checkpoints in chronological order. Each weave checkpoint contains a segmented weave digest of all traceability records generated within that checkpoint interval. The interval record layer is temporarily composed of multiple traceability records generated concurrently within the same checkpoint interval. There is no prevHash dependency between the traceability records within the interval record layer, allowing for parallel generation. S2: When a client needs to create a shared service link, it submits a link creation request to the shared service link traceability management system; after the system verifies the client's permissions, it creates the link and generates the initial weaving checkpoint W_0; The founding weaving checkpoint W_0 contains the following fields: checkpoint sequence number cpSeq=0, checkpoint closing timestamp cpTimestamp, the interval digest weaveDigest generated by the unique founding trace record P_0 of checkpoint W_0 through segmented weaving, recordCount=1, the hash of the previous checkpoint prevCheckpointHash, the list of public keys for the key period epochPublicKeys, and the checkpoint hash value checkpointHash; Set the link identifier linkId to the checkpointHash value of the initial weaving checkpoint W_0, so that the link identifier is cryptographically bound to the initial state of the traceability chain, and realizes a one-to-one cryptographic correspondence between the link identifier and the traceability chain. S3: The system returns the generated shared service link to the client; S4: When a client initiates a data access request through the shared service link, the system performs concurrent traceability record generation and checkpoint trigger weaving operations; S5: When it is necessary to trace and audit the access history of a shared service link, multi-granularity scalable verification supports the auditor to select the verification depth according to actual needs; S6: When the lifecycle of the shared service link ends, the system performs a sealing operation on the traceability chain; Once the sealing is complete, a sealing certificate is generated, the link is marked as sealed, and any new access requests and appending of traceability records are rejected.

2. The shared service link traceability management method according to claim 1, characterized in that: In step S1, the time window length T_window of the checkpoint interval is an adaptive parameter, and the adaptive adjustment method for the time window length is as follows: The average number of visits, C_avg, is defined as the ratio of the sum of the number of records in the most recent K intervals to the sum of the time spans. The system monitors the average access volume C_avg within the interval of the most recent K weaving checkpoints; when C_avg exceeds the preset high concurrency threshold C_high, the T_window is shortened; when C_avg is lower than the preset low concurrency threshold C_low, the T_window is extended. The T_window is between the preset lower limit T_min and the upper limit T_max.

3. The shared service link traceability management method according to claim 1, characterized in that: In step S1, the method for generating the interval summary weaveDigest includes the following steps: s11: The system sorts all traceability records within the current checkpoint interval in ascending order according to the record number seqNum, and divides them into several weaving segments Segment_i according to the preset segment length L; s12: For each weaving segment, the system concatenates the seqNum of each record in the segment with the recordHash in ascending order of seqNum and performs hash calculation to obtain the sequence number binding digest indexDigest_i; The segmentDigest_i for each weaving segment is calculated as follows: segmentDigest_i = HASH(segmentSeq || firstSeqNum || lastSeqNum ||recordCount_i || indexDigest_i); Where segmentSeq is the weaving segment number, firstSeqNum and lastSeqNum are the first and last record numbers in the weaving segment, respectively, and recordCount_i is the number of records in the weaving segment; s13: After obtaining the segmentDigest_i of all weaving segments, the system concatenates each segmentDigest_i in ascending order of segmentSeq and calculates the interval weaving summary: weaveDigest = HASH(cpSeq || segmentCount || segmentDigest_1 || segmentDigest_2 || … || segmentDigest_m); Where segmentCount is the number of weaving segments within the current checkpoint interval, and m is the total number of weaving segments; s14: Write the weaveDigest to the weave checkpoint and participate in the calculation of checkpointHash.

4. The shared service link traceability management method according to claim 1, characterized in that: Step S4 specifically includes the following steps: a1: Extract the link identifier linkId from the shared service link, and locate the source chain corresponding to the link and its current active range; The active interval refers to the checkpoint interval that is currently receiving new traceability records and has not yet been closed; there is only one active interval for the same traceability chain at any given time. a2: Check if the current active zone can still receive new records; detection methods include: Confirmation Time: Confirm that the time window for the current active period has expired. If it has expired, new records cannot be accepted; otherwise, new records will be accepted. Confirm capacity: Confirm that the cumulative number of records in the current active range has reached the threshold N_max. If the threshold has been reached, new records cannot be accepted; otherwise, new records are accepted. If the current active interval cannot accept new records, first perform the weaving checkpoint operation in step a3 to close the current active interval and create a new active interval, and then use the newly created active interval as the current active interval before performing step a4. If the current active range is still accepting new records, proceed to step a4; a3: The specific process of the weaving checkpoint operation is as follows: a31: Sort the hash values ​​of all trace records within the current checkpoint interval in ascending order according to the record number to obtain the sorted recordHash sequence; a32: The system divides the sorted source records into several weaving segments Segment_i according to the preset segment length L, and calculates the sequence number binding digest indexDigest_i and segment digest segmentDigest_i; The method for calculating the sequence number bound to the digest indexDigest_i is as follows: First, pair the seqNum of each record in Segment_i with the recordHash to obtain a pair. Then, concatenate all the pairs in the segment in ascending order of seqNum and perform hash calculation to obtain indexDigest_i. The segment digest segmentDigest_i is calculated as follows: segmentDigest_i = HASH(segmentSeq ||firstSeqNum || lastSeqNum || recordCount_i || indexDigest_i); the system concatenates each segmentDigest_i in ascending order of segmentSeq and calculates weaveDigest = HASH(cpSeq || segmentCount ||segmentDigest_1 || segmentDigest_2 || … || segmentDigest_m); a33: Calculate the checkpoint hash value of the current weave checkpoint: checkpointHash = HASH(cpSeq ||cpTimestamp || weaveDigest || recordCount || prevCheckpointHash ||epochPublicKeys); Where, prevCheckpointHash is the checkpointHash of the previous weaving checkpoint; a34: Append the current knitting checkpoint to the end of the knitting checkpoint sequence; a35: Start a new active range: increment cpSeq, reset the time window, clear the buffer, and initialize empty weaving segment cache and range weaving summary state; a4: Within the current active interval, generate a source trace record for this access; the generation of the source trace record is independent of the generation of source trace records for other concurrent accesses within the same checkpoint interval, with no prevHash dependency, and each source trace record supports parallel generation; a5: After each traceability record is generated, perform the following operations sequentially on the generated traceability record: a51 dual signature: First, the accessing client uses its current key period private key SK_epoch to sign the core field and generate clientSignature; after the system verifies the validity of clientSignature, it uses the system traceability signature private key to sign the concatenated core field and clientSignature to generate systemSignature. a52 record hash calculation: After the double signature is completed, the system will concatenate the traceability record fields other than the recordHash field itself in a preset order and calculate the recordHash; subsequent writes to the buffer and weaving digest inputs are based on this recordHash; The core fields include: seqNum, cpSeq, timestamp, clientId, operationType, dataScopeFingerprint, envDigest, and epoch; where clientId is the identifier of the access subject corresponding to this access request, and is not necessarily the same as the identifier of the creator of the shared service link. a53 Write Buffer: After the signature and recordHash calculations are completed, the traceability record and its seqNum and recordHash are written to the record buffer of the active region for the generation of weaveDigest when the checkpoint is closed; a54 Returns Traceability Credentials: Returns the traceability credentials for this access to the client. The traceability credentials include: the record hash value of this traceability record and the current record sequence number seqNum; a55 capacity check: After writing is completed, if the cumulative number of records in the active range has reached N_max, an a3 weaving operation is immediately triggered to create a brand new active range; a6: Request forwarding: According to the routing rules corresponding to the shared service link, forward this data access request to the target business system. When forwarding, attach a traceability identifier so that the business system can associate the traceability record in its own log. The traceability identifier includes: linkId and seqNum of this access.

5. The shared service link traceability management method according to claim 1, characterized in that: It also includes a private key management method; the private key management method adopts a forward-secure key evolution mechanism, specifically including the following steps: b1: Divide the entire lifecycle of the system into several key periods, each key period corresponding to a unique period number epoch; b2: Based on the elliptic curve public key cryptography algorithm, when the client registers for the first time, it generates an initial key pair (SK_0, PK_0) of the nth order signature curve through a signature key generation algorithm, where SK_0 is a random integer within the range of legal private key values ​​specified by the signature algorithm; PK_0 is the client's initial public key; PK_0 = SK_0 · G, where G is the base point of the signature elliptic curve; PK_0 is stored in the client certificate of the system after being signed by the CA, and serves as the trust anchor point of the client's public key chain; b3: Upon entering a new key period, the client performs the following key evolution operation: b31: The new private key for the current time period is obtained by iterating over the current private key using the one-way hash function and modulo n: SK_epoch = HASH(SK_{epoch-1}) mod n; if the result does not fall within the range of legal private key values ​​specified by the signature algorithm, then HASH(SK_{epoch-1} || 0x01) mod n is used to recalculate until the new private key falls within the range of legal private key values ​​specified by the signature algorithm; n is the order of the signature recommendation curve; b32: Calculate the public key for the corresponding time period: PK_epoch = SK_epoch · G; b33: Submit the tuple (epoch, PK_epoch) to the system through the established secure channel between the client and the system; b34: The system records the triple (clientId, epoch, PK_epoch) in the epochPublicKeys field of the currently active checkpoint, so that when the checkpoint is closed and participates in the weaving of the checkpoint sequence, PK_epoch is cryptographically anchored to the weaving checkpoint sequence. b35: The client overwrites and deletes SK_{epoch-1} in the secure storage area, retaining only SK_epoch for the traceability record signature of the current time period; b4: In each traceability record, the client signature clientSignature is signed using the private key SK_epoch corresponding to the key period when the record was generated, and the key period used for signing is marked in the traceability record by the epoch field. b5: During subsequent audit verification of clientSignature, the verifier reads PK_epoch from the epochPublicKeys field of the weaving checkpoint that records the epoch public key in the weaving checkpoint sequence based on the epoch field in the traceability record, and uses PK_epoch to perform signature verification of clientSignature.

6. The shared service link traceability management method according to claim 4, characterized in that: The weaving checkpoint operation is initiated based on preset checkpoint trigger conditions; Triggering condition 1: The time window for the current active period has expired; Triggering condition two: The cumulative number of traceability records within the current active range has reached the threshold N_max; Triggering condition three: The system receives a manual instruction to trigger the weaving process; If any one of the conditions is met, the weaving checkpoint operation is triggered.

7. The shared service link traceability management method according to claim 1, characterized in that: The multi-granularity scaling verification in step S5 includes: Granularity 1 is the weaving-level verification: it only verifies the chain consistency of checkpointHash of each weaving checkpoint in the weaving checkpoint sequence, that is, it verifies whether the prevCheckpointHash of each checkpoint is equal to the checkpointHash of the previous checkpoint, and verifies whether the checkpointHash of each checkpoint is equal to the HASH hash calculation result of its constituent fields. Granularity 2 is interval-level verification: Based on the successful weave-level verification, further verification is made to confirm whether the weaveDigest within the specified checkpoint interval is consistent with all traceability records within that interval. The verification method is as follows: obtain all traceability records within the interval, sort them by record number seqNum, redivide the weave segments according to the preset segment length L, recalculate the indexDigest_i, segmentDigest_i, and interval weaveDigest of each Segment_i, and compare them with the weaveDigest stored in the checkpoint. Granularity 3 is record-level verification: For a single specified traceability record, verify whether the clientSignature and systemSignature of the record are valid, locate the weave segment to which the record belongs, recalculate the indexDigest_i and segmentDigest_i of the segment, and then combine the segmentDigest sequence of the interval to verify that the record does indeed participate in the weaveDigest generation of the checkpoint interval.

8. The shared service link traceability management method according to claim 7, characterized in that: The multi-granularity scaling verification in step S5 also includes selective interval jump verification, specifically including the following operations: c1: The auditor specifies the verification time range [verification start time T_start, verification end time T_end]. The system locates the start checkpoint W_start and end checkpoint W_end that cover this time range based on the timestamp of each checkpoint. c2: For checkpoints outside the entire verification scope, perform weave-level verification: verify only the consistency of their checkpointHash chain; for checkpoints within the verification scope, perform interval-level verification: verify the consistency of weaveDigest interval by interval; for specific access records of particular concern to the auditor within the verification scope, perform record-level verification: the verification content includes signature verification and weave segment digest verification.

9. A shared service link traceability management system, used to execute the shared service link traceability management method according to any one of claims 1 to 8, characterized in that, It includes: a link creation module, a concurrent tracing record generation module, a checkpoint weaving module, a dual signature generation module, a multi-granularity verification module, an archiving module, and a key evolution management module; The link creation module is used to receive link creation requests from clients, perform permission verification, create shared service links, and generate a founding weaving checkpoint W_0. The concurrent tracing record generation module is used to generate tracing records in parallel for concurrent data access requests within each weaving checkpoint interval; there is no prevHash dependency between tracing records within the same checkpoint interval, and it supports multi-threaded or multi-instance parallel processing. The checkpoint weaving module is used to perform checkpoint weaving operations when the checkpoint triggering conditions are met. The dual signature generation module is used to coordinate the generation of digital signatures between the client and the system: it receives the clientSignature generated by the client using its forward security evolution private key for the core fields of the traceability record and verifies its validity, and generates the systemSignature using the system traceability signature private key; The multi-granularity verification module is used to support traceability verification at three granularities: weaving level, interval level, and record level, as well as selective interval jump verification. The sealing module is used to perform a forced weaving operation to generate a termination weaving checkpoint W_term when the link lifecycle ends, calculate the chain state fingerprint chainStateFingerprint, generate a sealing certificate, and mark the link as sealed. The key evolution management module is used to manage the forward security key evolution mechanism on the client and system sides. Specific operations include: triggering key evolution according to a preset period, generating a new time period private key seed through one-way hashing, calculating the corresponding time period public key, securely deleting the old time period private key, and recording the new time period public key in the epochPublicKeys field of the key period public key list of the current active weaving checkpoint.

10. The shared service link traceability management system according to claim 9, characterized in that: The shared service link traceability management system also includes: a checkpoint window adaptive module and an archive audit module; The checkpoint window adaptive module is used to monitor the average access volume C_avg within the K most recent knitting checkpoint intervals and dynamically adjust the time window length of the next checkpoint interval based on the time window length adaptive adjustment method. The archive audit module is used to perform archiving processing on traceability chain data of links that have been sealed and have exceeded the preset archiving period, migrate the woven checkpoint sequence data and interval traceability record data from online storage to archive storage medium, and generate integrity verification codes for archive data packages; the archived traceability chain supports offline auditing; when the auditor holds the archive data package and the sealing certificate, it supports full verification in a completely offline environment.

Images