A blockchain-based electronic evidence full-life-cycle storage and traceability method and system

Abstract

The application provides a blockchain-based electronic evidence full-life-cycle storage and traceability method and system, and relates to the technical field of blockchains.The steps of the application involve metadata collection, initial storage, incremental storage, operation chain construction, traceability request analysis, target block positioning and smart contract verification, etc.Through Byzantine consensus, Merkle tree structure and judicial node participation, the application realizes the full-process chain-based reliable recording of evidence from generation to verification, and enables the electronic evidence to have the capabilities of right confirmation, tamper prevention, traceability and judicial acceptance.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method and system for the full lifecycle storage and traceability of electronic evidence based on blockchain. Background Technology

[0002] Currently, the mainstream electronic evidence storage system still relies on a "centralized storage + third-party timestamp" model. This approach typically involves hosting the original file or its hash value on a cloud server and using an independent timestamp service provider to sign the generation time. While this architecture offers advantages in deployment cost and ease of operation, its security and reliability depend on a single or a few nodes. If a node fails, service is interrupted, or data is tampered with, the integrity of the evidence chain becomes difficult to maintain. Furthermore, traditional solutions often focus on the static hashing and on-chaining of the initial storage, lacking continuous recording and strong constraints for subsequent dynamic operations such as transfer, authentication, auditing, and permission transfer. This makes it difficult to meet the stringent requirements of judicial scenarios for "full-process traceability and non-repudiation of operations."

[0003] With the implementation of the "Electronic Signature Law of the People's Republic of China" and the Supreme People's Court's "Provisions on Several Issues Concerning the Collection, Preservation and Issuance of Electronic Data in Blockchain," industry technology is evolving from a "single node, single point in time" to a "multi-role, multi-stage" collaborative mechanism. Specifically, this manifests in the following ways: cross-institutional consortium blockchains with judicial organs, appraisal institutions, and notary offices as core nodes are gradually taking shape to provide final legal endorsement; sidechains, sharding, and Layer-2 channels are being used to handle high-concurrency state changes, and cross-chain relays are being used to achieve real-time synchronization between the main chain and the business chain; smart contracts are being used to automatically trigger evidence generation, permission changes, tiered authorization, and conditional destruction, achieving a closed-loop lifecycle from "generation—storage—circulation—expiration"; and simultaneously, privacy protection technologies such as zero-knowledge proofs and homomorphic encryption are being introduced to provide compliant data minimization and verifiable disclosure capabilities for sensitive evidence information.

[0004] While the introduction of blockchain technology has significantly improved tamper resistance, current solutions still suffer from systemic shortcomings: First, fragmented evidence storage only records the initial hash, failing to provide verifiable "incremental evidence" for subsequent supplementary evidence collection, re-identification, or multiple rounds of handover, leading to data gaps on the chain. Second, single-chain or small-scale consortium chain architectures still face single-point failures, cross-chain silos, and heterogeneous chain interoperability challenges, making it difficult to adapt to the needs of cross-domain evidence exchange and judicial mutual trust. Third, there is a lack of a mechanism to bind each operation event to a unique traceability code and solidify it on the chain, making it impossible to achieve high-granularity, visualized dynamic traceability. Fourth, authoritative nodes such as courts and notary offices are mostly still in the "offline verification" or "batch on-chain" stage, and have not yet formed a channel for real-time interaction with the business chain and automatic issuance of legally valid certificates, restricting the immediate availability of evidence on the judicial chain and the credibility of judgments. Summary of the Invention

[0005] In order to overcome the shortcomings of the existing technology, the purpose of this invention is to provide a method and system for the full life cycle storage and traceability of electronic evidence based on blockchain, so that electronic evidence has the complete ability to be identified, traceable, verifiable and judicially credible throughout its entire life cycle.

[0006] To achieve the above objectives, the present invention provides the following solution:

[0007] A blockchain-based method for the full lifecycle storage and traceability of electronic evidence, comprising:

[0008] Upon receiving an instruction to create electronic evidence, the evidence file hash, the creator's digital signature, timestamp, and content feature values ​​are collected to form a metadata set.

[0009] The metadata set is encapsulated into an initial evidence storage request and broadcast to the blockchain network. Each consensus node reaches a consensus based on the Byzantine fault tolerance algorithm, generates a block containing the initial evidence storage record, and writes it into the main chain.

[0010] When an evidence status change event is detected, the change operation information and the new content feature value are captured, and an incremental evidence storage request is generated based on the change operation information. After verification by the consensus node, the request is written into the new block, and the evidence status identifier is updated synchronously.

[0011] An evidence operation chain is generated by associating the initial block hash with the hashes of each new block using a Merkle tree structure, in order to record the entire operation sequence from generation to the present.

[0012] Receive the tracing request submitted by the verification party, and parse the unique identifier of the evidence and the target operation node;

[0013] Locate the target block along the evidence operation chain and generate a traceability certificate containing the target evidence record, the signature set of consensus nodes of the associated block, and the Merkel path proof;

[0014] The smart contract deployed on the judicial node is invoked to verify the legality of the traceability certificate and the verification result is returned to the verifier.

[0015] Preferably, upon receiving an instruction to create electronic evidence, the evidence file hash, the creator's digital signature, timestamp, and content feature values ​​are collected to form a metadata set, including:

[0016] Obtain the original files of electronic evidence and calculate the hash value using a preset hash algorithm as tamper-proof digest information;

[0017] A digital signature of the evidence creator is generated by invoking the user's private key; the digital signature is bound to the evidence hash value and the user's identity information.

[0018] A current timestamp is generated using a trusted time source, and the current timestamp is associated and bound with the hash value and the digital signature.

[0019] The evidence file is segmented according to a preset granularity to obtain several segments;

[0020] Calculate local sensitive hash values ​​for each of the aforementioned fragments to capture fine-grained changes in content;

[0021] All the aforementioned local hash values ​​are merged to construct a global feature vector, which characterizes the overall structure and distribution characteristics of the evidence content;

[0022] The hash value, the digital signature, the current timestamp, and the global feature vector are encapsulated into a metadata set in a unified format.

[0023] Preferably, the metadata set is encapsulated into an initial notarization request and broadcast to the blockchain network. Each consensus node reaches consensus based on the Byzantine fault tolerance algorithm, generates a block containing the initial notarization record, and writes it to the main chain, including:

[0024] The metadata set is formatted and encapsulated to generate the initial evidence storage request;

[0025] The initial evidence preservation request is broadcast to multiple consensus nodes in the preset consortium blockchain network via a blockchain client;

[0026] Each consensus node performs a consensus verification of the validity of the initial evidence storage request based on the Byzantine fault-tolerant algorithm; the consensus verification includes signature validity, timestamp reliability, and hash collision detection.

[0027] After consensus is reached, the selected proposing node constructs a new block and writes the record containing the initial evidence request into the data field of the new block;

[0028] The new block is added to the main blockchain, the chain status is updated, and an on-chain evidence number is generated.

[0029] Preferably, when an evidence status change event is detected, change operation information and new content feature values ​​are captured, and an incremental evidence storage request is generated based on the change operation information. After verification by the consensus node, the request is written into a new block, and the evidence status identifier is updated synchronously, including:

[0030] Monitor preset trigger event types; the event types include evidence transfer, copying, authentication, access, modification or destruction operations;

[0031] When a triggering event is detected, current operation information is collected; the current operation information includes the identity of the operation initiator, the operation type code, the operation timestamp, and the description of the operation target.

[0032] The modified evidence content is subjected to content feature extraction, and a new global feature vector is obtained by using the same feature generation algorithm as the initial evidence storage.

[0033] Construct an incremental evidence storage request by packaging the current operation information, the new global feature vector, the hash value of the previous block, and the unique evidence identifier into a structured request message.

[0034] The incremental evidence request is broadcast to the blockchain network, where consensus nodes verify the legality of the operation and the consistency of the content based on the Byzantine fault-tolerant algorithm.

[0035] After verification, the proposing node generates a new block, writes the incremental evidence storage request as transaction data into the new block, and adds the new block to the existing evidence operation chain.

[0036] Synchronously update the current state identifier of the evidence on the chain.

[0037] Preferably, an evidence operation chain is generated by associating the initial block hash with the hashes of each new block using a Merkle tree structure, to record the entire operation sequence from generation to the present, including:

[0038] Based on the chronological order of the operational events in the evidence lifecycle, extract the hash values ​​of the corresponding blocks, denoted as H0, H1, ..., H2. n Where H0 is the hash of the initial evidence storage block;

[0039] Construct a binary Merkle tree, treating all hash values ​​as leaf nodes, pairing them up sequentially and iteratively calculating the parent node hashes until a unique root node hash H is generated. root ;

[0040] The block hash H generated for each new operation i The update is performed using the following recursive formula:

[0041]

[0042] in, This represents the Merklegen hash after introducing the t-th operation block. H represents the root hash of the previous state. t Let Hash(·) be the block hash corresponding to the t-th operation, where || represents string concatenation and Hash(·) represents the preset cryptographic hash function.

[0043] After each root hash update, Write the state to the blockchain state storage and generate the corresponding operation sequence identifier. Used to indicate the complete operational path of the current evidence; where... This indicates that the evidence will be uniquely identified by an ID. e Operation number t and the current root hash The paths are pieced together to form a traceable, dynamic index path;

[0044] The operation sequence identifier C t It serves as a dynamic tracking index for the evidence operation chain, and is simultaneously written to the sidechain or IPFS.

[0045] Preferably, the cryptographic hash function is either Keccak256 or SHA3.

[0046] Preferably, the process of receiving a tracing request submitted by the verifier and parsing the unique identifier of the evidence and the target operation node includes:

[0047] Receive a data packet of a tracing request submitted by the verifier, the data packet containing unique evidence identification information and description information of the target operation node;

[0048] The data packet undergoes integrity verification and digital signature verification to confirm the authenticity of the request source and ensure that the contained evidence identifiers and operation requests have not been tampered with.

[0049] Based on the unique evidence identifier, the initial evidence storage record, current status identifier, and evidence operation chain corresponding to the unique evidence identifier are retrieved and located in the blockchain.

[0050] The description information of the target operation node is parsed; the description information includes the operation time range, operation type and operation entity identifier, which is used to assist in locating the source node;

[0051] The evidence operation chain is traversed and matched to find the target operation node that matches the description information.

[0052] Preferably, the target block is located along the evidence operation chain, and a traceability certificate containing the target evidence record, the signature set of the consensus nodes of the associated block, and the Merkel path proof is generated, including:

[0053] Based on the unique evidence identifier and target operation node description information extracted from the tracing request, the corresponding target block is determined in the evidence operation chain;

[0054] Extract the complete evidence record corresponding to the current operation from the target block; the complete evidence record includes the operation type, timestamp, operation subject, and content feature values ​​before and after the change;

[0055] Obtain the consensus node signature set associated with the target block; the signature set is used to prove that the block has been unanimously recognized by multiple nodes in the consortium blockchain and has tamper-proof effectiveness;

[0056] Starting from the initial notarized block, the path nodes of the target block in the operation chain are traced back level by level, and a complete link proof containing all intermediate hash paths is constructed to verify the position and continuity of the target block in the operation chain.

[0057] The target evidence record, consensus node signature set, and link proof are encapsulated into the traceability certificate in a standard format, and marked with a unique evidence identifier and generation timestamp for subsequent verification by the verifier.

[0058] Preferably, the process involves invoking a smart contract deployed on a judicial node to verify the legality of the traceability certificate and returning the verification result to the verifier, including:

[0059] Submit the generated traceability certificate data packet to the smart contract interface deployed on the judicial node;

[0060] The smart contract automatically parses the content of the data packet and performs legality checks on the timestamp, operation type, and evidence status in the target evidence record to determine whether it is within the validity period, legal permissions, and predefined format.

[0061] Verify whether the consensus node signature set covers the number of nodes under the preset consensus threshold, and verify the consistency between the signature and the public key of the consortium blockchain node to ensure that the block is indeed generated by the consensus of legitimate nodes;

[0062] Based on the link path proof, the hash path is compared sequentially from the initial block to the target block to verify the continuity and immutability of the target block in the evidence operation chain;

[0063] If all verifications pass, the smart contract will automatically generate a verification success response and return it to the verifier along with the corresponding credential digest. If any verification fails, a verification failure response and corresponding error code information will be generated for the verifier to determine and handle.

[0064] A blockchain-based system for the full lifecycle storage and traceability of electronic evidence includes:

[0065] The metadata collection unit is used to collect the evidence file hash, creator's digital signature, timestamp, and content feature value when receiving an electronic evidence creation instruction, forming a metadata set;

[0066] The initial evidence submission unit is used to encapsulate the metadata set into an initial evidence submission request and broadcast it to the blockchain network. Each consensus node reaches a consensus based on the Byzantine fault tolerance algorithm, generates a block containing the initial evidence submission record, and writes it into the main chain.

[0067] The incremental evidence generation unit is used to capture change operation information and new content feature values ​​when an evidence status change event is detected, and generate an incremental evidence request based on the change operation information. After verification by the consensus node, the request is written into a new block and the evidence status identifier is updated synchronously.

[0068] The operation chain construction unit is used to generate an evidence operation chain by associating the initial block hash with the hashes of each new block through a Merkle tree structure, so as to record the entire operation sequence from generation to the present.

[0069] The tracing request parsing unit is used to receive tracing requests submitted by the verifier and parse the unique identifier of the evidence and the target operation node.

[0070] The tracing certificate generation unit is used to locate the target block along the evidence operation chain and generate a tracing certificate containing the target evidence record, the signature set of the consensus nodes of the associated block, and the Merkel path proof.

[0071] The judicial verification unit is used to invoke the smart contract deployed on the judicial node to verify the legality of the traceability certificate and return the verification result to the verifier.

[0072] According to specific embodiments provided by the present invention, the present invention discloses the following technical effects:

[0073] 1. This invention achieves on-chain ownership confirmation of evidence at the time of evidence generation by uniformly encapsulating the hash value, signature, timestamp, and content feature value extracted during the generation of electronic evidence and immediately writing them into the initial block of the blockchain network. This overcomes the one-sidedness of existing technologies that only store hash digests and ignore semantic features, and significantly improves the credibility and verifiability of the original evidence.

[0074] 2. By constructing an incremental evidence storage mechanism that supports state change event triggering, this invention can record and upload operation details to the blockchain in real time when evidence is transferred, modified, or authenticated, establishing a complete evidence operation chain, thereby effectively solving the problem of "fragmented evidence storage" in existing solutions that cannot record the subsequent flow path of evidence.

[0075] 3. This invention adopts a Merkle tree-based structured organization method to connect all operation nodes in series to form a dynamic and scalable evidence operation chain. Combined with the on-chain path backtracking mechanism, it provides a verifiable operation sequence and path proof for each tracing, thus solving the technical shortcoming of traditional schemes that lack a cross-node dynamic tracing mechanism.

[0076] 4. During the tracing process, by receiving the unique identifier of the evidence and the description information of the operation node submitted by the verifier, and locating the target block on the chain and generating the tracing certificate, the tracing results are ensured to have operational context and full-link path support, which significantly enhances the consistency and non-repudiation of evidence verification across time points and business links.

[0077] 5. By leveraging smart contracts deployed on judicial nodes, this invention can automatically verify the legality of the generated traceability certificates. The verification process covers signature consistency, path integrity, and node ownership validity, effectively solving the problem of "insufficient judicial connection" caused by the lack of real-time interaction between traditional blockchain evidence storage platforms and authoritative nodes such as courts and notary offices.

[0078] 6. The blockchain network adopts a layered hybrid architecture. The main chain is led by judicial institution nodes to ensure data compliance and credibility, while the side chains carry frequent operations and synchronize key states to the main chain, balancing performance and security. This improves cross-domain evidence management and heterogeneous chain interoperability from the system architecture level. Attached Figure Description

[0079] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0080] Figure 1 A flowchart of the method provided in an embodiment of the present invention;

[0081] Figure 2 This is a schematic diagram of the system structure provided in an embodiment of the present invention. Detailed Implementation

[0082] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0083] The purpose of this invention is to provide a blockchain-based method and system for the full lifecycle storage and traceability of electronic evidence. By constructing a blockchain operation chain and smart contract verification system covering the entire process of evidence generation, circulation, modification and verification, it realizes a closed loop of credible storage and auditable traceability of electronic evidence throughout its entire lifecycle, from confirmation of rights, operation, verification to judicial application. This comprehensively solves the problems of fragmentation, isolation, staticity and unusability of existing evidence storage methods.

[0084] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0085] Figure 1The method flowchart provided in the embodiments of the present invention is as follows: Figure 1 As shown, this invention provides a blockchain-based method for the full lifecycle storage and traceability of electronic evidence, including:

[0086] Step 100: Upon receiving the instruction to create electronic evidence, collect the evidence file hash, creator's digital signature, timestamp, and content feature value to form a metadata set;

[0087] Step 200: Encapsulate the metadata set into an initial evidence storage request and broadcast it to the blockchain network. Each consensus node reaches a consensus based on the Byzantine fault tolerance algorithm, generates a block containing the initial evidence storage record, and writes it into the main chain.

[0088] Step 300: When an evidence status change event is detected, capture the change operation information and the new content feature value, generate an incremental evidence storage request based on the change operation information, write it into the new block after verification by the consensus node, and update the evidence status identifier synchronously.

[0089] Step 400: Generate an evidence operation chain by associating the initial block hash with the hashes of each new block using a Merkle tree structure, in order to record the entire operation sequence from generation to the present.

[0090] Step 500: Receive the tracing request submitted by the verification party, and parse the unique identifier of the evidence and the target operation node;

[0091] Step 600: Locate the target block along the evidence operation chain and generate a traceability certificate containing the target evidence record, the signature set of consensus nodes of the associated block, and the Merkel path proof;

[0092] Step 700: Call the smart contract deployed on the judicial node to verify the legality of the traceability certificate and return the verification result to the verifier.

[0093] Specifically, in step 100 of this embodiment, upon receiving the electronic evidence creation instruction, the system first obtains the original electronic evidence file to be stored and performs a hash operation on the entire file using a preset hash algorithm (such as SHA-256) to generate a unique digest value used to identify the integrity of the file content. Subsequently, the system calls the evidence creator's local key management module and uses their private key to digitally sign the hash value. This signature binds the hash digest to the user's identity information and ensures the ownership and non-repudiation of the evidence. Next, the system calls a trusted time source (such as a national time service or a consensus time node within a consortium blockchain) to generate a current timestamp and binds the timestamp together with the aforementioned hash value and digital signature to form a complete original metadata field with time attributes. To further enhance the structural expressiveness of the evidence content and the accuracy of subsequent identification, the system divides the original evidence file into equal-length segments according to a preset segmentation granularity (e.g., each 128KB segment), obtaining several data segments. For each shard, a Locality Sensitive Hash (LSH) algorithm (such as SimHash or LSH) is applied to extract local hash values ​​that are sensitive to content changes, and these values ​​are represented in a vectorized structure. The system merges the local hash vectors of all shards to generate a global feature vector, which characterizes the overall structure and distribution characteristics of the evidence content, thus balancing static integrity with dynamic semantic recognition. Finally, the system encapsulates the hash values, digital signatures, timestamps, and the global feature vector into a structured data format (such as JSON or Protocol Buffers), serving as the metadata set in the initial evidence storage request, ready to be broadcast to the blockchain network.

[0094] In one embodiment of the present invention, the Locality Sensitive Hash (LSH) algorithm can be implemented using the SimHash algorithm. For each file segment, its n-gram features based on text or binary content are first extracted, and then each feature is mapped to a hash bit string of fixed dimensions. The hash results of all segments are weighted, accumulated, and normalized to finally form a global feature vector of length 256 bits, which is used to represent the feature summary of the entire evidence content. During the fusion process, no manual weight setting is introduced; instead, the contribution of each segment is automatically adjusted based on the content entropy of each segment, thereby ensuring that the generated feature vector has high sensitivity to minor modifications and can be well integrated with the subsequent state change detection mechanism.

[0095] Optionally, in step 200 of this embodiment, after collecting the evidence file hash, digital signature, trusted timestamp, and content feature value, the metadata set will be encapsulated according to a preset format specification to form a standardized initial evidence storage request. Preferably, the encapsulation format adopts a JSON-LD compatible data structure, and the fields include a unique evidence identifier, original data digest, creator identifier, signature data, and time attribute. In this embodiment, the initial evidence storage request is broadcast to the consortium blockchain network through a blockchain client deployed on a terminal or server. The consortium blockchain includes several nodes with consensus permissions, such as court nodes, notary office nodes, and appraisal agency nodes. In this embodiment, after receiving the initial evidence storage request, each consensus node in the consortium blockchain performs consistency verification of the validity of the request based on the Byzantine Fault Tolerance (PBFT) algorithm or its variants. The verification includes: verifying the digital signature contained in the request to confirm that it was indeed generated by the creator's private key; verifying the trustworthiness of the timestamp to ensure that it originates from a time node recognized in the consortium blockchain and is within the allowed time window; and performing conflict detection on the evidence hash value to prevent duplicate evidence storage. Consensus is considered complete when a node that meets the consensus threshold sends a verification response. In this embodiment, the proposal node, selected through a round-robin process, is responsible for constructing a new block and writing the initial evidence storage request data into the data field of the new block. Finally, the new block is added to the end of the blockchain main chain, and a unique on-chain evidence storage number is generated, serving as an anchor reference for subsequent dynamic evidence storage and traceability operations.

[0096] Specifically, in this embodiment, the Byzantine Fault Tolerance algorithm is preferably the Practical Byzantine Fault Tolerance algorithm (PBFT). This algorithm requires at least 2f+1 nodes to reach a consensus before a transaction can be confirmed as valid, provided that no more than f nodes are malicious or faulty. For example, in a scenario where the consensus network contains 4 judicial nodes, the system sets f=1, and at least 3 nodes must return a consensus response before the block generation stage can begin. Signature validity verification uses the Elliptic Curve Digital Signature Algorithm (ECDSA), and timestamp verification is based on a trusted network time source compared to the current local clock with an error not exceeding ±5 seconds. Hash collision detection checks whether the evidence hash and identifier fields already exist in the main chain state database; if they do, it is marked as a duplicate submission and rejected from the chain.

[0097] Specifically, in step 300 of this embodiment, the dynamic evidence storage mechanism for changes in evidence status is implemented through an event monitoring module. This module is configured with several predefined trigger event types, including evidence transfer, copying, authentication, access, modification, and destruction. When the system detects any of these events, it immediately collects current operation information, including the identity identifier of the operation initiator (such as the user's public key registered on the blockchain), operation type code (such as "TRF" for transfer and "EDT" for modification), operation timestamp, and operation target description (such as the target node ID or the judicial entity to which it belongs). This embodiment uses the same content feature extraction algorithm as the initial evidence storage to re-perform fragmentation, local hash calculation, and vector fusion on the changed evidence file to obtain a new global feature vector reflecting the evidence content status in the current version.

[0098] Furthermore, in this embodiment, the operation information, the new global feature vector, the hash value of the previous block, and the unique identifier of the evidence are packaged together into a structured incremental evidence storage request. Preferably, the request format adopts a JSON structure, and the field order and naming rules are consistent with the initial evidence storage to ensure cross-chain compatibility. In this embodiment, the incremental evidence storage request is broadcast to the consortium blockchain network through a blockchain client. The consensus node performs consistency verification of the request's legality based on the Byzantine fault tolerance algorithm. The verification content includes the validity of identity authorization, the consistency between feature values ​​and operation types, whether the timestamp is within a reasonable range, and the continuity of the hash chain. When the verification is successful, the current proposing node generates a new block and writes the request as transaction data into the new block. This new block is added to the end of the existing evidence operation chain, forming a new state node. At the same time, the on-chain evidence state identifier is updated synchronously to reflect the latest operation state and feature hash.

[0099] Furthermore, in this embodiment, the operation type code adopts a three-digit string encoding format, with the following presets: TRF (Transfer), CPY (Copy), EDT (Edit), DEL (Delete), AUD (Audit), and EXM (Examine). The operation type code is extensible; when added, it should be registered in the on-chain registry and confirmed by the judicial node. The generation process of the global feature vector is consistent with the initial evidence storage, using a 128KB partitioning granularity. The SimHash algorithm is used to extract local hashes from each partition, which are then weighted, merged, and normalized to form a fixed-length feature vector of 256 bits. This feature vector is highly sensitive to local modifications and is suitable for subsequent operation consistency verification and version difference identification.

[0100] Specifically, in step 400 of this embodiment, to achieve continuous recording and complete traceability of each operational event in the evidence lifecycle, this embodiment constructs an evidence operation chain based on block hashes in the blockchain. Specifically, the system extracts the hash value of each relevant block sequentially according to the time sequence of the evidence from initial creation, state change to the current node, and inputs it as a leaf node into a preset binary Merkle tree structure. Each leaf node is paired sequentially and iteratively calculated using a preset hash function until a unique root node hash is formed, representing the full-chain operational state of the evidence in the current version. When a new operation occurs on the evidence (such as transfer, authentication, access, etc.) and a new block is generated, this embodiment automatically appends the hash value of the new block to the current Merkle tree and updates the tree structure. The updated root node hash value is written to the main chain state storage area as a credential identifier of the latest operational state. Simultaneously, the system generates an operation sequence identifier based on the root hash, the unique evidence identifier, and the operation sequence, used to indicate the complete path of the current on-chain operation. This operation sequence identifier will be synchronously written to the sidechain node or IPFS network to achieve state visibility and off-chain data mapping in a cross-chain environment, thereby forming a dynamic, scalable, and verifiable evidence operation chain structure.

[0101] In this embodiment, the Merkle tree is constructed based on the block hash generated by each operation on the evidence, employing a bottom-up binary structure that supports dynamic insertion. Each time a new operation occurs, a new leaf node is appended to the tree, and the hashes of all affected intermediate nodes are recalculated, ultimately updating the root hash value. To achieve a traceable chain index, this embodiment concatenates the unique identifier of the evidence, the sequential number of the operation in the entire chain, and the current root hash to form an operation sequence identifier. This identifier is logically equivalent to a timeline locator for the evidence, does not rely on central node storage, and maintains consistency across heterogeneous networks such as judicial nodes, sidechain nodes, and IPFS. This structure is particularly suitable for scenarios involving multi-node collaborative verification, off-chain evidence snapshot alignment, and version comparison.

[0102] Specifically, in step 500 of this embodiment, when the verifier initiates a tracing request, this embodiment receives the data packet submitted by it. The data packet is encapsulated in a structured format (such as JSON) and includes at least the unique evidence identifier and the description information of the target operation node. This embodiment first performs integrity verification and signature verification on the data packet to ensure that the request source is authentic and has not been tampered with. Specifically, this embodiment calls the public key used by the verifier to reverse decrypt the digital signature and verify whether the signature matches the request content and the sender's identity; if the verification fails, subsequent processing is rejected. This mechanism can effectively prevent illegal tracing requests from interfering with the on-chain operation path. After the signature verification is successful, this embodiment retrieves the initial evidence storage block, the current state identifier, and the evidence operation chain corresponding to the identifier in the blockchain state database based on the unique evidence identifier. Subsequently, this embodiment parses the description information of the target operation node. This description information includes the operation time range (e.g., January 1, 2024 to March 31, 2024), operation type (e.g., access, modification, transfer), and operation entity identifier (e.g., node ID, judicial institution code, or user public key). This embodiment sequentially traverses each block node in the retrieved evidence operation chain, matching the timestamp, operation type, and operation entity information to locate the target operation node consistent with the description information, and marks its block location for use by the subsequent traceability certificate generation module.

[0103] Furthermore, in this embodiment, the unique evidence identifier adopts a fixed-length encoding format, composed of the initial evidence storage block hash and the creator's user public key digest, possessing global uniqueness and facilitating cross-chain identification. The description information of the target operation node is defined using a three-field combination: the time range field uses timestamp upper and lower limits (e.g., "start":1672531200,"end":1680307200); the operation type uses predefined operation type codes within the system (e.g., TRF-transfer, AUD-access, EDT-modification); and the operation entity identifier field records the on-chain identity identifier of the operation initiator, such as the institution ID registered on the consortium blockchain or the user's public key hash. By jointly judging these three types of fields, the system achieves precise location of the traceability target, supporting fuzzy queries and fast indexing in multi-node scenarios.

[0104] Specifically, in step 600 of this embodiment, after receiving a verified tracing request, a matching operation is performed in the operation chain structure corresponding to the evidence based on the unique identifier of the evidence and the description information of the target operation node contained in the request, to determine the corresponding target block. After successful matching, this embodiment extracts a complete evidence record of the operation from the target block. The evidence record includes: the type identifier of the operation (e.g., modification, transfer), the operation execution timestamp, the identity identifier of the operation initiator (e.g., user public key or on-chain node ID), and the content feature values ​​before and after the operation. The above information constitutes a complete evidence snapshot of the operation, used to support on-chain behavior auditing and judicial tracing.

[0105] Upon locating the target block, this embodiment further extracts the signature set of the nodes involved in the consensus confirmation of that block to verify that the operation has been confirmed by a majority of nodes in the consortium blockchain network, possessing non-repudiation and tamper-proof properties. Subsequently, starting from the initial evidence-stored block, this embodiment traces back to the target block sequentially according to the blockchain connection order, extracting the hash values ​​of all intermediate blocks to construct a Merkel path structure for generating a link integrity proof. Finally, this embodiment encapsulates the complete evidence-stored record, the consensus node signature set, and the link proof constituted by the Merkel path into a standard format traceability credential data package. The data package also includes a unique identifier for the evidence and a current generation timestamp, used to mark the source and validity period of this traceability result for subsequent legality verification by the verifier.

[0106] In this embodiment, the consensus node signature set refers to the signature fragment formed when each node participating in the consensus within the consortium blockchain signs the new block digest information using its private key during the generation of the target block. The system records the node ID, signature time, signature content, and public key index information for each signature. This set is extracted from the traceability certificate to confirm that the block was consistently confirmed by the legal consensus nodes and was not forged. Merkel path proof refers to recording the hash value of each parent node and its relative position in the tree structure (such as the left or right subtree) during the process of tracing back from the target block to the initial evidence block. This path information can be used to prove the existence and positional continuity of the target block in the entire evidence operation chain structure. The system supports encoding the above structured data in the form of a hash list and uniformly encapsulating and outputting it using the platform's standard on-chain traceability certificate format (such as JSON-LD or Protocol Buffers).

[0107] Specifically, in step 700 of this embodiment, after the traceability certificate is generated, it is submitted to the smart contract interface deployed on the judicial node in the form of a structured data packet. The smart contract, as an automated verification module, first parses the received traceability certificate content, including fields such as the target evidence record, consensus node signature set, Merkel path information, unique evidence identifier, and generation timestamp. After parsing, the contract verifies the validity period of the timestamp field in the target evidence record, determining whether it is within the time tolerance range recognized by the current system. It also checks whether the operation type is legally registered and whether the evidence status is consistent with the judicial node record, ensuring that the evidence storage operation has structural compliance and logical rationality. Provided that the format and status verification passes, this embodiment further calls the contract's internal signature verification logic to check whether the consensus node signature set attached to the traceability certificate meets the minimum consensus threshold set by the consortium blockchain, and verifies whether each signature is indeed generated by a registered legitimate node public key. The contract also compares the hash values ​​on the target block path level by level, starting from the initial block, based on the Merkel path information, ensuring that the target block is continuous in position, structurally complete, and has not been tampered with in the operation chain. If all the above verification items pass, the smart contract will generate a verification success response and automatically return the credential digest information (such as digest hash and verification time) to the verifier; if any verification fails, the contract will return a failure response and the corresponding error code for the verifier to audit and manually handle.

[0108] Optionally, in this embodiment, the consensus threshold refers to the minimum requirement for the number of node signatures in the consortium blockchain consensus mechanism, typically set to at least two-thirds of the total number of participating nodes. For example, in a consortium blockchain with 10 consensus nodes, at least 7 valid signatures are required for it to be considered valid. The system pre-configures a node registry in the contract, containing the identity number, public key, and status information of each consensus node. Path verification employs a Merkel path matching mechanism, requiring a complete hash path tracing back from the target block to the initial block. Each level of the path must provide the hashes and position markers of adjacent nodes (such as left or right nodes). The contract internally verifies the existence of the target node and the consistency of the link through step-by-step combination calculations, ensuring that the traceability certificate is unforgeable and difficult to deny.

[0109] Corresponding to the above methods, such as Figure 2 As shown, this embodiment also provides a blockchain-based electronic evidence lifecycle storage and traceability system, including:

[0110] The metadata collection unit is used to collect the evidence file hash, creator's digital signature, timestamp, and content feature value when receiving an electronic evidence creation instruction, forming a metadata set;

[0111] The initial evidence submission unit is used to encapsulate the metadata set into an initial evidence submission request and broadcast it to the blockchain network. Each consensus node reaches a consensus based on the Byzantine fault tolerance algorithm, generates a block containing the initial evidence submission record, and writes it into the main chain.

[0112] The incremental evidence generation unit is used to capture change operation information and new content feature values ​​when an evidence status change event is detected, and generate an incremental evidence request based on the change operation information. After verification by the consensus node, the request is written into a new block and the evidence status identifier is updated synchronously.

[0113] The operation chain construction unit is used to generate an evidence operation chain by associating the initial block hash with the hashes of each new block through a Merkle tree structure, so as to record the entire operation sequence from generation to the present.

[0114] The tracing request parsing unit is used to receive tracing requests submitted by the verifier and parse the unique identifier of the evidence and the target operation node.

[0115] The tracing certificate generation unit is used to locate the target block along the evidence operation chain and generate a tracing certificate containing the target evidence record, the signature set of the consensus nodes of the associated block, and the Merkel path proof.

[0116] The judicial verification unit is used to invoke the smart contract deployed on the judicial node to verify the legality of the traceability certificate and return the verification result to the verifier.

[0117] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to the method section.

[0118] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for the full lifecycle storage and traceability of electronic evidence based on blockchain, characterized in that, include: Upon receiving an instruction to create electronic evidence, the evidence file hash, the creator's digital signature, timestamp, and content feature values ​​are collected to form a metadata set. The metadata set is encapsulated into an initial evidence storage request and broadcast to the blockchain network. Each consensus node reaches a consensus based on the Byzantine fault tolerance algorithm, generates a block containing the initial evidence storage record, and writes it into the main chain. When an evidence status change event is detected, the change operation information and the new content feature value are captured, and an incremental evidence storage request is generated based on the change operation information. After verification by the consensus node, the request is written into the new block, and the evidence status identifier is updated synchronously. An evidence operation chain is generated by associating the initial block hash with the hashes of each new block using a Merkle tree structure, in order to record the entire operation sequence from generation to the present. Receive the tracing request submitted by the verification party, and parse the unique identifier of the evidence and the target operation node; Locate the target block along the evidence operation chain and generate a traceability certificate containing the target evidence record, the signature set of consensus nodes of the associated block, and the Merkel path proof; The smart contract deployed on the judicial node is invoked to verify the legality of the traceability certificate and the verification result is returned to the verifier. An evidence operation chain is generated by associating the initial block hash with the hashes of each new block using a Merkle tree structure, to record the entire operation sequence from generation to the present, including: Based on the chronological order of the operational events in the evidence lifecycle, extract the hash value of the corresponding block, denoted as . ;in This is the hash of the initial evidence storage block; Construct a binary Merkle tree, treating all hash values ​​as leaf nodes, pairing them up in order and iteratively calculating the parent node hash until a unique root node hash is generated. ; The block hash generated for each new operation The update is performed using the following recursive formula: ； in, Indicates the introduction of the first Merkelgen hash after one operation block, This represents the root hash of the previous state. For the first The block hash corresponding to each operation This represents a string concatenation operation. This represents the preset cryptographic hash function; After each root hash update, Write the state to the blockchain state storage and generate the corresponding operation sequence identifier. This is used to indicate the complete operational path of the current evidence; where, This indicates that the evidence will be uniquely identified. Operation number Compared with the current root hash The paths are pieced together to form a traceable, dynamic index path; The operation sequence identifier As a dynamic tracking index for the evidence operation chain, it is simultaneously written to the sidechain or IPFS. After locating the target block, a traceability certificate is constructed, which includes the target evidence record, the signature set of consensus nodes of the associated block, and the Merkel path proof. The traceability certificate is encapsulated in a unified structured data format and marked with a unique evidence identifier and a generation timestamp. The smart contract deployed on the judicial node is invoked to automatically verify the legality of the traceability certificate. The legality verification includes timestamp validity verification, operation type compliance verification, and evidence status consistency verification. After verification, a judicial confirmation result is generated and written into the blockchain state storage. The content feature values ​​include a global feature vector based on electronic evidence fragmentation. During its generation, the contribution of each fragment is automatically adjusted according to the content entropy of each fragment to ensure that the generated feature vector has high sensitivity to minor modifications and can be well integrated with the state change detection mechanism.

2. The method for full lifecycle storage and traceability of electronic evidence based on blockchain according to claim 1, characterized in that, Upon receiving an instruction to create electronic evidence, the system collects the evidence file hash, the creator's digital signature, timestamp, and content feature values ​​to form a metadata set, including: Obtain the original files of electronic evidence and calculate the hash value using a preset hash algorithm as tamper-proof digest information; A digital signature of the evidence creator is generated by invoking the user's private key; the digital signature is bound to the evidence hash value and the user's identity information. A current timestamp is generated using a trusted time source, and the current timestamp is associated and bound with the hash value and the digital signature. The evidence file is segmented according to a preset granularity to obtain several segments; Calculate local sensitive hash values ​​for each of the aforementioned fragments to capture fine-grained changes in content; All the aforementioned local sensitive hash values ​​are merged to construct a global feature vector to characterize the overall structure and distribution characteristics of the evidence content; The hash value, the digital signature, the current timestamp, and the global feature vector are encapsulated into a metadata set in a unified format.

3. The method for full lifecycle storage and traceability of electronic evidence based on blockchain according to claim 1, characterized in that, The metadata set is encapsulated into an initial notarization request and broadcast to the blockchain network. Each consensus node reaches consensus based on the Byzantine fault-tolerant algorithm, generates a block containing the initial notarization record, and writes it to the main chain, including: The metadata set is formatted and encapsulated to generate the initial evidence storage request; The initial evidence preservation request is broadcast to multiple consensus nodes in the preset consortium blockchain network via a blockchain client; Each consensus node performs a consensus verification of the validity of the initial evidence storage request based on the Byzantine fault-tolerant algorithm; the consensus verification includes signature validity, timestamp reliability, and hash collision detection. After consensus is reached, the selected proposing node constructs a new block and writes the record containing the initial evidence request into the data field of the new block; The new block is added to the main blockchain, the chain status is updated, and an on-chain evidence number is generated.

4. The method for full lifecycle storage and traceability of electronic evidence based on blockchain according to claim 1, characterized in that, When an evidence status change event is detected, the change operation information and the new content feature value are captured, and an incremental evidence storage request is generated based on the change operation information. After verification by the consensus node, the request is written into a new block, and the evidence status identifier is updated synchronously, including: Monitor preset trigger event types; the event types include evidence transfer, copying, authentication, access, modification or destruction operations; When a triggering event is detected, current operation information is collected; the current operation information includes the identity of the operation initiator, the operation type code, the operation timestamp, and the description of the operation target. The modified evidence content is subjected to content feature extraction, and a new global feature vector is obtained by using the same feature generation algorithm as the initial evidence storage. Construct an incremental evidence storage request by packaging the current operation information, the new global feature vector, the hash value of the previous block, and the unique evidence identifier into a structured request message. The incremental evidence request is broadcast to the blockchain network, where consensus nodes verify the legality of the operation and the consistency of the content based on the Byzantine fault-tolerant algorithm. After verification, the proposing node generates a new block, writes the incremental evidence storage request as transaction data into the new block, and adds the new block to the existing evidence operation chain. Synchronously update the current state identifier of the evidence on the chain.

5. The method for full lifecycle storage and traceability of electronic evidence based on blockchain according to claim 1, characterized in that, The cryptographic hash function is either Keccak256 or SHA3.

6. The method for full lifecycle storage and traceability of electronic evidence based on blockchain according to claim 1, characterized in that, Receive the tracing request submitted by the verification party, parse the unique identifier of the evidence and the target operation node, including: Receive a data packet of a tracing request submitted by the verifier, the data packet containing unique evidence identification information and description information of the target operation node; The data packet is subjected to integrity verification and digital signature verification to confirm the authenticity of the request source and to ensure that the evidence identifier and operation request contained therein have not been tampered with. Based on the unique evidence identifier, the initial evidence storage record, current status identifier, and evidence operation chain corresponding to the unique evidence identifier are retrieved and located in the blockchain. The description information of the target operation node is parsed; the description information includes the operation time range, operation type and operation entity identifier, which is used to assist in locating the source node; The evidence operation chain is traversed and matched to find the target operation node that matches the description information.

7. The method for full lifecycle storage and traceability of electronic evidence based on blockchain according to claim 1, characterized in that, Locate the target block along the evidence operation chain and generate a traceability credential containing the target evidence record, the signature set of consensus nodes of the associated block, and the Merkel path proof, including: Based on the unique identifier of the evidence extracted from the tracing request and the description information of the target operation node, the corresponding target block is determined in the evidence operation chain; Extract the complete evidence record corresponding to the current operation from the target block; the complete evidence record includes the operation type, timestamp, operation subject, and content feature values ​​before and after the change; Obtain the consensus node signature set associated with the target block; the signature set is used to prove that the block has been unanimously recognized by multiple nodes in the consortium blockchain and has tamper-proof effectiveness; Starting from the initial notarized block, the path nodes of the target block in the operation chain are traced back level by level, and a complete link proof containing all intermediate hash paths is constructed to verify the position and continuity of the target block in the operation chain. The target evidence record, consensus node signature set, and link proof are encapsulated into the traceability certificate in a standard format, and marked with a unique evidence identifier and generation timestamp for subsequent verification by the verifier.

8. The method for full lifecycle storage and traceability of electronic evidence based on blockchain according to claim 1, characterized in that, The process involves invoking a smart contract deployed on a judicial node to verify the legitimacy of the traceability certificate and returning the verification result to the verifier, including: Submit the generated traceability certificate data packet to the smart contract interface deployed on the judicial node; The smart contract automatically parses the content of the data packet and performs legality checks on the timestamp, operation type, and evidence status in the target evidence record to determine whether it is within the validity period, legal permissions, and predefined format. Verify whether the consensus node signature set covers the number of nodes under the preset consensus threshold, and verify the consistency between the signature and the public key of the consortium blockchain node to ensure that the block is indeed generated by the consensus of legitimate nodes; Based on the link path proof, the hash path is compared sequentially from the initial block to the target block to verify the continuity and immutability of the target block in the evidence operation chain; If all verifications pass, the smart contract will automatically generate a verification success response and return it to the verifier along with the corresponding credential digest. If any verification fails, a verification failure response and corresponding error code information will be generated for the verifier to determine and handle.

9. A blockchain-based system for the full lifecycle storage and traceability of electronic evidence, characterized in that, The system applied to the blockchain-based method for full lifecycle storage and traceability of electronic evidence according to any one of claims 1 to 8, the system comprising: The metadata collection unit is used to collect the evidence file hash, creator's digital signature, timestamp, and content feature value when receiving an electronic evidence creation instruction, forming a metadata set; The initial evidence submission unit is used to encapsulate the metadata set into an initial evidence submission request and broadcast it to the blockchain network. Each consensus node reaches a consensus based on the Byzantine fault tolerance algorithm, generates a block containing the initial evidence submission record, and writes it into the main chain. The incremental evidence generation unit is used to capture change operation information and new content feature values ​​when an evidence status change event is detected, and generate an incremental evidence request based on the change operation information. After verification by the consensus node, the request is written into a new block and the evidence status identifier is updated synchronously. The operation chain construction unit is used to generate an evidence operation chain by associating the initial block hash with the hashes of each new block through a Merkle tree structure, so as to record the entire operation sequence from generation to the present. The tracing request parsing unit is used to receive tracing requests submitted by the verifier and parse the unique identifier of the evidence and the target operation node. The tracing certificate generation unit is used to locate the target block along the evidence operation chain and generate a tracing certificate containing the target evidence record, the signature set of the consensus nodes of the associated block, and the Merkel path proof. The judicial verification unit is used to invoke the smart contract deployed on the judicial node to verify the legality of the traceability certificate and return the verification result to the verifier.

Images