Block chain-based electronic evidence full-life-cycle evidence storage and tracing method and system

Abstract

The invention provides a block chain-based electronic evidence full-life-cycle evidence storage and tracing method and system, and relates to the technical field of block chains. The method comprises the steps of metadata collection, initial evidence storage, incremental evidence storage, operation chain construction, traceability request analysis, target block positioning, intelligent contract verification and the like, and through Byzantine consensus, a Merkel tree structure and judicial node participation, credible recording on a whole process chain of evidence from generation to verification is achieved. Therefore, the electronic evidence has the capabilities of right confirmation, tampering prevention, traceability and judicial credit collection.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchains, in particular to a method and system for storing and tracing the whole life cycle of electronic evidence based on a blockchain. BACKGROUND

[0002] At present, the electronic evidence storage system is still dominated by the "centralized storage + third-party timestamp" mode. The implementation path is mostly to host the original file or its hash value on a cloud server, and to complete the signature marking of the generation time point with the help of an independent timestamp service provider. Although this architecture has advantages in terms of deployment cost and operational convenience, its security and credibility depend on a single or a small number of nodes: once a node fails, service is interrupted, or data is tampered with, the evidence chain will be difficult to maintain integrity. In addition, traditional solutions focus on the static hash on-chain of the first storage link, and lack continuous recording and strong constraints for subsequent dynamic operations such as transfer, identification, audit, and permission alternation, making it difficult to meet the strict requirements of the judicial scene for "full-process traceability and operation non-repudiation".

[0003] With the implementation of the "Electronic Signature Law of the People's Republic of China" and the "Provisions of the Supreme People's Court on Issues Related to the Collection, Storage and Provision of Electronic Data Based on Blockchain", the industry technology is evolving from "single node, single time point" to "multi-role, multi-stage" collaborative mechanism. Specifically, a cross-agency consortium chain with the core nodes of judicial organs, identification agencies, and notarization agencies is gradually taking shape to provide final legal endorsement; side chains, sharding, and Layer-2 channels are used to carry high-concurrency state changes, and cross-chain relays are used to realize real-time synchronization between the main chain and the business chain; smart contracts are used to automatically trigger evidence generation, permission changes, hierarchical authorization, and conditional destruction, realizing the full life cycle closed loop from "generation - storage - transfer - invalidation"; at the same time, privacy protection technologies such as zero-knowledge proof and homomorphic encryption are introduced to provide compliant data minimization and verifiable disclosure capabilities for sensitive evidence information.

[0004] Although the introduction of blockchain technology has significantly improved the tamper-proofing capability, the current solution still has systemic deficiencies: first, the fragmented storage mode only records the initial hash, without providing verifiable "incremental evidence" for subsequent supplementary evidence collection, re-identification, or multiple rounds of handover, resulting in a data gap on the chain; second, single-chain or small-scale consortium chain architecture still faces the problems of single-point failure, cross-chain island, and heterogeneous chain mutual recognition, making it difficult to adapt to cross-domain evidence exchange and judicial mutual trust needs; third, there is a lack of a mechanism to bind each operation event to a unique trace code and solidify it on the chain, making it impossible to achieve high-granularity, visual dynamic tracing; fourth, authoritative nodes such as courts and notarization offices mostly stay 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 legal evidence, restricting the immediate availability and adjudication acceptance of judicial evidence on the chain. SUMMARY

[0005] In order to overcome the deficiencies of the prior art, the purpose of the present application is to provide a blockchain-based electronic evidence full life cycle storage and traceability method and system, which makes the electronic evidence have the complete ability of right confirmation, traceability, verification and judicial acceptance in the full life cycle.

[0006] To achieve the above purpose, the present application provides the following scheme:

[0007] A blockchain-based electronic evidence full life cycle storage and traceability method, comprising:

[0008] Upon receiving an electronic evidence creation instruction, collecting evidence file hash, creator digital signature, timestamp and content feature value to form a metadata set;

[0009] The metadata set is encapsulated as an initial storage request and broadcast to the blockchain network, and each consensus node performs consensus according to the Byzantine fault-tolerant algorithm to generate a block containing the initial storage record and write it to the main chain;

[0010] When detecting an evidence state change event, capturing change operation information and a new content feature value, and generating an incremental storage request based on the change operation information, which is written into a new block after being verified by the consensus node, and the evidence state identifier is updated synchronously;

[0011] According to the initial block hash and each new block hash, an evidence operation chain is generated through a Merkle tree structure association to record all operation sequences from generation to the present;

[0012] Receiving a traceability request submitted by a verification party, parsing the evidence unique identifier and the target operation node;

[0013] Locating the target block along the evidence operation chain, generating a traceability voucher containing the target storage record, a set of associated block consensus node signatures and a Merkle path proof;

[0014] Calling the smart contract deployed on the judicial node to verify the legality of the traceability voucher and returning the verification result to the verification party.

[0015] Preferably, upon receiving an electronic evidence creation instruction, collecting evidence file hash, creator digital signature, timestamp and content feature value to form a metadata set, comprising:

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

[0017] Generate a digital signature of the evidence creator by calling the user private key; the digital signature binds the evidence hash value and the user identity information;

[0018] generating a current timestamp by a trusted time source, and associating the current timestamp with the hash value and the digital signature;

[0019] slicing the evidence file according to a preset granularity to obtain a plurality of slices;

[0020] calculating a local sensitive hash value for each of the slices to capture fine-grained changes in the content;

[0021] fusing all the local hash values to construct a global feature vector to represent the overall structure and distribution characteristics of the evidence content;

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

[0023] Preferably, the metadata set is encapsulated as an initial evidence storage request and broadcast to the blockchain network, and each consensus node performs consensus according to a Byzantine fault-tolerant algorithm to generate a block containing an initial evidence storage record and write it to the main chain, including:

[0024] formatting and encapsulating the metadata set to generate the initial evidence storage request;

[0025] broadcasting the initial evidence storage request to a plurality of consensus nodes in a preset consortium chain network through a blockchain client;

[0026] Each of the consensus nodes performs consistency verification on the validity of the initial evidence storage request according to a Byzantine fault-tolerant algorithm; the content of the consistency verification includes signature legality, timestamp credibility, and hash collision detection;

[0027] After consensus is reached, a new block is constructed by a selected proposal node, and a record containing the initial evidence storage request is written to the data field of the new block;

[0028] The new block is added to the blockchain main chain, updating the chain state and generating a chain storage number.

[0029] Preferably, when a change in evidence state 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, which is written to a new block after being verified by the consensus nodes, and the evidence state identifier is updated synchronously, including:

[0030] listening to a preset trigger event type; the event type includes evidence transfer, copy, identification, access, modification, or destruction operation;

[0031] When a trigger 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 operation target description;

[0032] Performing content feature extraction on the changed evidence content, and using the same feature generation algorithm as the initial evidence to obtain a new global feature vector;

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

[0034] Broadcasting the incremental evidence request to the blockchain network, and verifying the operation legality and content consistency by the consensus nodes according to the Byzantine fault tolerance algorithm;

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

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

[0037] Preferably, the evidence operation chain is generated by associating the initial block hash and each new block hash through a Merkle tree structure to record all operation sequences from generation to the present, including:

[0038] According to the chronological order of each operation event in the evidence life cycle, the hash values of the corresponding blocks are extracted, denoted as H0, H1,...,H n ; wherein H0 is the initial evidence block hash;

[0039] Constructing a binary Merkle tree, taking all hash values as leaf nodes, pairing and iteratively calculating parent node hash in order until generating a unique root node hash H root ;

[0040] For each newly added operation block hash H i , update it through the following recursive formula:

[0041]

[0042] wherein, represents the Merkle root hash after introducing the tth operation block, represents the root hash in the previous state, H t is the block hash corresponding to the tth operation, || represents the string concatenation operation, and Hash(·) represents a preset encryption hash function;

[0043] After each root hash update, is written into the blockchain state storage, and the corresponding operation sequence identifier is generated to indicate the complete operation path of the current evidence; wherein, Evidence Unique ID e Operation Sequence Number t and Current Root Hash Splicing to form a traceable dynamic index path

[0044] Operation Sequence Identification C t As a dynamic tracking index of evidence operation chain, while writing to side chain or IPFS synchronously.

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

[0046] Preferably, receiving a traceability request submitted by a verifier, parsing the evidence unique identification and the target operation node, including:

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

[0048] Performing integrity check and digital signature verification on the data packet to confirm the authenticity of the request source and ensure that the evidence identification and operation request contained therein are not tampered with;

[0049] Based on the evidence unique identification, retrieving and locating the initial evidence record corresponding to the evidence unique identification, the current state identification and the evidence operation chain corresponding to the current state identification in the blockchain;

[0050] Parsing the description information of the target operation node; the description information includes operation time range, operation type and operation entity identification, which is used to assist in locating the traceability node;

[0051] Traverse matching in the located evidence operation chain to find the target operation node consistent with the description information.

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

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

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

[0055] Obtaining the consensus node signature set associated with the target block; the signature set is used to prove that the block is approved by multiple nodes in the alliance chain and has tamper-proof effect;

[0056] Backtracking the path nodes of the target block in the operation chain from the initial storage block, and constructing a complete link proof containing all intermediate hash paths, for proving the location and continuity of the target block in the operation chain;

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

[0058] Preferably, the legality of the traceability certificate is verified by calling the smart contract deployed on the judicial node, and the verification result is returned to the verifier, including:

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

[0060] The content of the data packet is automatically parsed by the smart contract, and the timestamp, operation type and evidence state in the target storage record are legally verified to determine whether they are within the valid period, legal authority and predefined format range;

[0061] Verifying whether the consensus node signature set covers the number of nodes under the preset consensus threshold, and verifying the consistency of the signature and the alliance chain node public key to ensure that the block is generated by legal node consensus;

[0062] According to the link path proof, the hash paths from the initial block to the target block are compared in sequence to verify the continuity and tamper resistance of the target block in the evidence operation chain;

[0063] If all verifications pass, the smart contract automatically generates a verification passed response and returns the corresponding certificate summary to the verifier; if any verification fails, a verification failed response and corresponding error code information are generated for the verifier to determine and handle.

[0064] A blockchain-based electronic evidence full life cycle storage and traceability system, comprising:

[0065] A metadata acquisition unit for acquiring evidence file hash, creator digital signature, timestamp and content feature value to form a metadata set when receiving an electronic evidence creation instruction;

[0066] An initial storage submission unit for encapsulating the metadata set as an initial storage request and broadcasting it to the blockchain network, and each consensus node performs consensus according to the Byzantine fault tolerance algorithm to generate a block containing the initial storage record and write it to the main chain;

[0067] An incremental evidence generation unit is configured to capture change operation information and a new content feature value when a piece of evidence state change event is detected, generate an incremental evidence request based on the change operation information, write the incremental evidence request into a new block after verification by the consensus node, and update the evidence state identifier synchronously;

[0068] An operation chain construction unit is configured to generate an evidence operation chain by associating initial block hashes and new block hashes through a Merkle tree structure, so as to record all operation sequences from generation to the present;

[0069] A traceability request analysis unit is configured to receive a traceability request submitted by a verifier, and analyze an evidence unique identifier and a target operation node;

[0070] A traceability certificate generation unit is configured to locate a target block along the evidence operation chain, and generate a traceability certificate containing a target evidence record, a consensus node signature set associated with the target block, and a Merkle path proof;

[0071] A judicial verification unit is configured to call an intelligent contract deployed on a judicial node to verify the legality of the traceability certificate, and return a verification result to the verifier.

[0072] According to the embodiments of the present application, the following technical effects are achieved:

[0073] 1. The present application encapsulates the hash value, signature, timestamp and content feature value of the electronic evidence extracted in the generation link, and writes them into the initial block of the block chain network immediately, so as to realize the on-chain authentication of the evidence generation time point, overcome the one-sidedness of the prior art in which only the hash digest is stored and the semantic features are ignored, and significantly improve the credibility and verifiability of the original evidence.

[0074] 2. The present application constructs an incremental evidence mechanism that supports state change event triggering, and can record and chain the operation details in real time when the evidence is transferred, modified or identified, so as to establish a complete evidence operation chain, thereby effectively solving the problem of "fragmented evidence storage" in the prior art in which the subsequent flow path of the evidence cannot be recorded.

[0075] 3. The present application adopts a structured organization method based on the Merkle tree, links all operation nodes to form a dynamically expandable evidence operation chain, and combines a chain path backtracking mechanism to provide a verifiable operation sequence and path proof for each traceability, thereby solving the technical shortcoming of the lack of a cross-node dynamic traceability mechanism in the conventional scheme.

[0076] 4. In the traceability process, the evidence unique identifier and operation node description information submitted by the verifier are received, the target block is located on the chain, and the traceability certificate is generated, so as to ensure that the traceability result has operation context and full-link path support, and significantly enhance the evidence verification coherence and anti-repudiation across time points and business links.

[0077] 5. By means of the smart contract deployed on the judicial node, the application can automatically verify the legality of the generated traceable certificate, and the verification process covers signature consistency, path integrity and node ownership validity, effectively solving the problem of "insufficient judicial connection" due to the lack of real-time interaction between the traditional block chain storage platform and the authoritative nodes such as the court and the notary office.

[0078] 6. The block chain network adopts a hierarchical hybrid architecture, the main chain is dominated by the judicial institution node to ensure data compliance and public trust, the side chain carries out frequent operations and synchronizes the key state to the main chain, and the performance and safety are considered, so that the cross-domain evidence management and heterogeneous chain mutual recognition ability are improved from the system architecture level. BRIEF DESCRIPTION OF DRAWINGS

[0079] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the following will briefly introduce the drawings needed in the embodiments. Obviously, the drawings in the following description are only some embodiments of the application, and for those skilled in the art, other drawings can also be obtained without creative labor.

[0080] Figure 1 The method flowchart provided for the embodiments of the application;

[0081] Figure 2 The system structure schematic diagram provided for the embodiments of the application. DETAILED DESCRIPTION

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

[0083] The purpose of the application is to provide a kind of electronic evidence full life cycle based on block chain Storage and traceability method and system, by building the block chain operation chain and smart contract verification system covering the whole process of evidence generation, transfer, change and verification, realize the full life cycle of electronic evidence from the right, operation, verification to judicial application Trusted storage and auditable traceability closed loop, fully solve the problem of fragmentation, isolation, static and unusable of existing storage mode.

[0084] In order to make the above-mentioned purposes, features and advantages of the application more obvious and easy to understand, the application will be further described in detail below with reference to the drawings and specific embodiments.

[0085] Figure 1The method flowchart provided for the embodiments of the present application is shown in Figure 1 The present application provides a blockchain-based electronic evidence full-life-cycle storage and traceability method, which comprises the following steps:

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

[0087] Step 200: Encapsulate the metadata set as an initial storage request and broadcast it to the blockchain network, and each consensus node performs consensus according to the Byzantine fault-tolerant algorithm to generate a block containing the initial storage record and write it to the main chain;

[0088] Step 300: When a change in the evidence state is detected, capture the change operation information and new content feature value, and generate an incremental storage request based on the change operation information, which is written to a new block after being verified by the consensus node, and the evidence state identifier is updated synchronously;

[0089] Step 400: Generate an evidence operation chain by associating the initial block hash and each new block hash through a Merkle tree structure to record all operation sequences from generation to the present;

[0090] Step 500: Receive a traceability request submitted by a verifier, and parse the evidence unique identifier and target operation node;

[0091] Step 600: Locate the target block along the evidence operation chain, and generate a traceability voucher containing the target storage record, associated block consensus node signature set and Merkle path proof;

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

[0093] Specifically, in step 100 of the embodiment, after receiving the electronic evidence creation instruction, the system first acquires 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 for identifying the integrity of the file content. Subsequently, the system calls the local key management module of the evidence creator to digitally sign the hash value using its private key, which binds the hash digest and user identity information and ensures the attribution and anti-fraud of the evidence. Then, the system calls a trusted time source (such as a national time service or a consensus time node in a consortium chain) to generate a current timestamp, and binds the timestamp with the hash value and digital signature to form an original metadata field with time attributes. In order to further enhance the structural expression ability of the evidence content and the accuracy of subsequent identification, the system divides the original evidence file into equal-length fragments according to a preset fragmentation granularity (for example, each 128KB is a fragment), obtaining a plurality of fragment data. For each fragment, a local sensitive hash algorithm (such as SimHash, LSH, etc.) is applied to extract a local hash value that can perceive content changes and is represented in a vector structure. The system fuses the local hash vectors of all fragments to generate a global feature vector for representing the overall structure and distribution characteristics of the evidence content, thereby balancing static integrity and dynamic semantic recognition. Finally, the system encapsulates the hash value, digital signature, timestamp, and global feature vector into a structured data format (such as JSON or Protocol Buffers) as a metadata set in the initial storage request, ready to be broadcast to the blockchain network.

[0094] In an embodiment of the present application, the local sensitive hash algorithm can be implemented using the SimHash algorithm. For each file fragment, the n-gram features based on text or binary content are first extracted, and then each feature is mapped to a fixed-dimensional hash bit string. After weighting and accumulating all fragment hash results, a global feature vector with a length of 256 bits is finally formed to represent the feature digest of the entire evidence content. In the fusion process, no manual weight setting is introduced, but the content entropy of each fragment is automatically adjusted to determine the contribution of each fragment, thereby ensuring that the generated feature vector has high sensitivity to minor modifications and can be well connected with the subsequent state change detection mechanism.

[0095] Optionally, after the collection of the evidence file hash, digital signature, trusted timestamp and content feature value is completed in step 200 of the embodiment, the metadata set will be encapsulated in a preset format specification to form a standardized initial evidence storage request. Preferably, the encapsulation format adopts a data structure compatible with JSON-LD, and the fields include evidence unique identification, original data digest, creator identification, signature data and time attribute. The initial evidence storage request is broadcast to the alliance chain network by the blockchain client deployed in the terminal or server in the embodiment, and the alliance chain includes a plurality of nodes with consensus authority, such as court nodes, notary office nodes, and authentication agency nodes. In the embodiment, each consensus node in the alliance chain verifies the validity of the request according to the Byzantine fault-tolerant algorithm (PBFT or its variants) after receiving the initial evidence storage request. The verification content includes: verifying the digital signature contained in the request to confirm that it is generated by the creator private key; verifying the timestamp for trustworthiness to ensure that it comes from a recognized time node in the alliance chain and is within the allowed time window; and performing conflict detection on the evidence hash value to prevent duplicate storage. When the nodes that meet the consensus threshold feed back the verification pass response, it is considered that the consensus is completed. In the embodiment, the proposal node selected by the round node is responsible for constructing a new block, and the initial evidence storage request data is written into the data field of the new block. Finally, the new block is added to the end of the main chain of the blockchain, and a unique on-chain evidence number is generated as an anchor reference for subsequent dynamic evidence storage and traceability operations.

[0096] Specifically, in the embodiment, the Byzantine fault-tolerant algorithm is preferably the practical Byzantine fault-tolerant algorithm PBFT. This algorithm requires at least 2f+1 nodes to reach a consensus before confirming the validity of a transaction under the condition that no more than f nodes are malicious or faulty. For example, in a scenario where the consensus network includes 4 judicial nodes, the system sets f=1, and at least 3 nodes return a consistent response before entering the block generation stage. The signature legality verification adopts the elliptic curve digital signature algorithm (ECDSA), and the timestamp verification is based on the comparison between the trusted network time source and the current local clock error within the range of ±5 seconds. Hash conflict detection is performed by querying whether the evidence hash and identifier field already exist in the main chain state database. If they exist, they are marked as duplicate submissions and rejected from the chain.

[0097] Specifically, in step 300 of the embodiment, the dynamic evidence state change storage mechanism is implemented through an event listening module. The module is configured with several pre-defined trigger event types, including transfer, copy, identification, access, modification and destruction of evidence, etc. When the system detects the occurrence of any of the above events, it immediately collects the current operation information, including the identity of the operation initiator (such as the on-chain registered user public key), the operation type code (such as "TRF" for transfer and "EDT" for modification), the operation timestamp and the operation target description (such as the target node ID or the jurisdiction entity to which it belongs). The embodiment uses the same content feature extraction algorithm as the initial storage to re-execute the fragmentation processing, local hash calculation and vector fusion on the changed evidence file, to obtain a new global feature vector to reflect the current version of the evidence content state.

[0098] Further, the embodiment packages the operation information, the new global feature vector, the previous block hash value and the evidence unique identifier together as a structured incremental storage request. Preferably, the request format adopts a JSON structure, and the field order and naming rules remain consistent with the initial storage to ensure cross-chain compatibility. The embodiment broadcasts the incremental storage request to the consortium chain network through the blockchain client, and the consensus nodes verify the consistency of the request legality according to the Byzantine fault tolerance algorithm, including the validity of the identity authorization, the consistency between the feature value and the operation type, whether the timestamp is within a reasonable interval, the hash chain continuity, etc. When the verification is passed, the current proposal node generates a new block, and writes the request as transaction data into the new block. The new block is added to the tail of the existing evidence operation chain to form 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] Further, in the embodiment, the operation type code adopts a three-character string encoding format, and the preset is as follows: TRF (Transfer), CPY (Copy), EDT (Edit), DEL (Delete), AUD (Audit) and EXM (Examine). The operation type code is extensible, and when new, it should be registered on the chain and confirmed by the judicial node. The generation process of the global feature vector is consistent with the initial storage, and the segmentation granularity is 128KB, the SimHash algorithm is used to extract the local hash of each segment, and then the weighted combination and normalization are performed to form a fixed-length feature vector with a length of 256 bits. The feature vector has strong sensitivity to local modification and is suitable for subsequent operation consistency verification and version difference identification.

[0100] Specifically, in step 400 of the embodiment, in order to realize continuous recording and complete traceability of each operation event in the life cycle of evidence, the embodiment constructs an evidence operation chain based on block hashes in the blockchain. Specifically, the system extracts the hash value of each relevant block in the time sequence of the evidence from initial creation, state change to the current node, and inputs it as a leaf node into the preset binary Merkle tree structure. Each leaf node is paired in order, and the preset hash function is used for iterative calculation until a unique root node hash is formed to represent the full chain operation state of the evidence under the current version. When a new operation (such as transfer, identification, access, etc.) of the evidence occurs and a new block is generated, the embodiment will automatically append the hash value of the new block to the current Merkle tree and update the tree structure. The updated root node hash value is written into the main chain state storage area as a proof of the latest operation state. At the same time, the system generates an operation sequence identifier based on the root hash, the unique identifier of the evidence, and the operation sequence, which is used to indicate the complete path of the current on-chain operation. The operation sequence identifier is written into the side chain node or IPFS network at the same time, which is used to realize the state visibility and off-chain data mapping in the cross-chain environment, thereby forming a set of dynamic and expandable, verifiable evidence operation chain structure.

[0101] In the embodiment, the construction of the Merkle tree is based on the block hash generated by each operation of the evidence, adopts a bottom-up binary structure, and supports dynamic insertion. Each time a new operation occurs, a new leaf node is added to the tree, and the hash of all affected intermediate nodes is recalculated, and finally the root hash value is updated. In order to realize the traceable link index, the embodiment splices the unique identifier of the evidence, the sequential number of the operation in the whole chain, and the current root hash to form an operation sequence identifier. The identifier is logically equivalent to the time axis locator of the evidence, and does not depend on the central node storage, and can maintain consistency among heterogeneous networks such as judicial nodes, side chain nodes, IPFS, etc. This structure is particularly suitable for multi-node collaborative verification, off-chain evidence snapshot alignment and version comparison scenarios.

[0102] Specifically, in step 500 of the embodiment, in the embodiment, when the verification party initiates a traceability request, the embodiment receives the submitted data packet thereof, which is encapsulated in a structured format (such as JSON) and at least contains evidence unique identification information and description information of the target operation node. The embodiment first performs integrity check and signature verification on the data packet to ensure that the request comes from a real source and has not been tampered with. Specifically, the embodiment calls the public key used by the verification party to decrypt the digital signature in reverse, checks whether the signature matches the request content and the sender's identity, and rejects subsequent processing if the verification fails. Through this mechanism, illegal traceability requests can be effectively prevented from interfering with the on-chain operation path. After the signature verification is passed, the embodiment retrieves the initial evidence block corresponding to the identification, the current state identification, and the evidence operation chain corresponding to the state based on the evidence unique identification in the blockchain state database. Subsequently, the embodiment parses the description information of the target operation node, which includes the operation time range (such as January 1, 2024 to March 31, 2024), the operation type (such as access, modification, transfer, etc.), and the operation entity identification (such as node ID, judicial agency code, or user public key). The embodiment sequentially traverses each block node in the retrieved evidence operation chain, matches the timestamp, operation type, and operation subject information, locates the target operation node consistent with the description information, and marks the block position thereof for subsequent call by the generation module of the traceability certificate.

[0103] Further, in the embodiment, the evidence unique identification adopts a fixed-length encoding format, which is composed of the initial evidence block hash and the creator user public key digest, and has global uniqueness, which is convenient for cross-chain identification. The description information of the target operation node is defined in a three-field combination manner, the time range field adopts a timestamp upper and lower limit pair (such as "start":1672531200,"end":1680307200); the operation type adopts a system-predefined operation type code (such as TRF-transfer, AUD-access, EDT-modification); and the operation entity identification field records the on-chain identity identifier of the operation initiator, such as the agency ID or user public key hash registered in the alliance chain. The system realizes accurate positioning of the traceability target through joint judgment of the three types of fields, supports fuzzy query and rapid indexing in the multi-node scenario.

[0104] Specifically, in step 600 of the embodiment, after receiving the qualified traceability request, the evidence unique identifier and the target operation node description information contained in the request are used to perform a matching operation in the operation chain structure corresponding to the evidence to determine the corresponding target block. After the matching is successful, the embodiment extracts the complete evidence record of the operation from the target block, which includes the type identifier of the operation (such as modification, transfer, etc.), the operation execution timestamp, the operation initiator identity (such as a user public key or a chain node ID), and the content feature values before and after the operation. The above information constitutes a complete evidence snapshot of the operation, which is used to support chain behavior auditing and judicial traceability.

[0105] While locating the target block, the embodiment further extracts the signature set of the nodes participating in the consensus when the block is confirmed, to verify that the operation has been confirmed by a majority of nodes in the alliance chain network, and has non-repudiation and tamper resistance. Subsequently, starting from the initial evidence block, the embodiment traces back to the target block in sequence according to the block link order, extracts all intermediate block hash values, and constructs a Merkle path structure for generating a link integrity proof. Finally, the embodiment encapsulates the complete evidence record, the consensus node signature set, and the Merkle path link proof into a standard format of traceability voucher data packet. The data packet also contains the unique identifier of the evidence and the current generation timestamp, which are used to mark the source and validity period of the traceability result for subsequent legality verification by the verifier.

[0106] In the embodiment, the consensus node signature set refers to the signature fragments formed by the nodes participating in the consensus in the alliance chain signing the digest information of the new block using their private keys when the target block is generated. The system records the node ID, signature time, signature content, and public key index information of each signature. The set is extracted in the traceability voucher to confirm that the block is confirmed by the statutory consensus nodes rather than being forged. The Merkle path proof refers to the process of tracing back from the target block to the initial evidence block, recording the hash value of each parent node and its relative position in the tree structure (such as left subtree or right subtree) in sequence. This path information can be used to prove the existence and position 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 the data in the standard on-chain traceability voucher format (such as JSON-LD or Protocol Buffers) of the platform.

[0107] Specifically, in step 700 of the embodiment, after the generation of the traceable certificate, the certificate is submitted to the smart contract interface deployed on the judicial node in the form of a structured data packet. As an automated verification module, the smart contract first parses the content of the received traceable certificate, including the target storage record, the consensus node signature set, the Merkle path information, the evidence unique identifier, and the generation timestamp. After parsing, the contract verifies the validity period of the timestamp field in the target storage record to determine whether it is within the current system-recognized time tolerance range, checks whether the operation type is legally registered, and whether the evidence state is consistent with the judicial node record to ensure that the storage operation has structural compliance and logical rationality. On the premise that the format and state verification is passed, the embodiment further calls the internal signature verification logic of the contract to check whether the consensus node signature set attached in the traceable certificate meets the minimum consensus threshold set by the alliance chain, and verifies whether each signature is generated by the registered legal node public key. The contract also compares the hash values on the target block path from the initial block according to the Merkle path information to ensure that the target block is continuous in the operation chain, the structure is complete, and it has not been tampered with. If all the above verification items are passed, the smart contract generates a response result of successful verification and automatically returns the certificate summary information (such as the summary hash and verification time) to the verification party; if any item fails, the contract will return a failure response and the corresponding error code for the verification party to audit and manually process.

[0108] Optionally, in the embodiment, the consensus threshold refers to the minimum requirement for the number of node signatures in the consensus mechanism of the alliance chain, which is usually set to more than two-thirds of the total number of participating nodes. For example, in the case of 10 consensus nodes in the alliance chain, at least 7 legal signatures are required to be considered valid. The system preinstalls a node registration table in the contract, which includes the identity number, public key, and state information of each consensus node. The path verification uses the Merkle path matching mechanism, which requires providing a complete hash path from the target block to the initial block. Each level of the path needs to provide the adjacent node hash and position marker (such as the left node or the right node). The contract internally verifies the existence and link consistency of the target node by gradually combining and calculating to ensure that the traceable certificate cannot be forged and is difficult to deny.

[0109] Corresponding to the above method, as shown in Figure 2 , the embodiment also provides an electronic evidence full life cycle storage and traceability system based on a block chain, which comprises:

[0110] A metadata acquisition unit is configured to acquire an evidence file hash, a creator digital signature, a timestamp, and a content feature value to form a metadata set when receiving an electronic evidence creation instruction;

[0111] An initial evidence submission unit is configured to encapsulate the metadata set as an initial evidence submission request and broadcast to the blockchain network, each consensus node performs consensus according to a Byzantine fault-tolerant algorithm, generates a block containing an initial evidence record and writes it to the main chain.

[0112] An incremental evidence generation unit is configured to capture change operation information and new content feature values when detecting an evidence state change event, generate an incremental evidence request based on the change operation information, write it to a new block after verification by the consensus node, and update the evidence state identifier synchronously.

[0113] An operation chain construction unit is configured to generate an evidence operation chain by associating initial block hashes and new block hashes through a Merkle tree structure to record all operation sequences from generation to the present.

[0114] A traceability request analysis unit is configured to receive a traceability request submitted by a verifier, analyze the evidence unique identifier and target operation node.

[0115] A traceability certificate generation unit is configured to locate a target block along the evidence operation chain and generate a traceability certificate containing the target evidence record, a consensus node signature set of associated blocks and a Merkle path proof.

[0116] A judicial verification unit is configured to call a smart contract deployed on a judicial node to verify the legality of the traceability certificate and return the verification result to the verifier.

[0117] Each embodiment in the specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between embodiments can be mutually referred to. For the system disclosed in the embodiments, the description is relatively simple because it corresponds to the method disclosed in the embodiments. The relevant parts can be referred to the method part.

[0118] The principles and implementation modes of the present application are described by using specific examples. The above embodiment description is only used to help understand the method and core idea of the present application. For those skilled in the art, the specific implementation mode and application range can be changed according to the idea of the present application. In conclusion, the content of the specification should not be understood as a limitation of the present application.

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.

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 hash values ​​are merged to construct a global feature vector, which characterizes 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, 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 values ​​of the corresponding blocks, denoted as H0, H1, ..., H2. n Where H0 is the hash of the initial evidence storage block; 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 ; The block hash H generated for each new operation i The update is performed using the following recursive formula: 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. 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 current root hash The paths are pieced together to form a traceable, dynamic index path; 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.

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

7. 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 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. 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.

8. 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 evidence identifier and target operation node description information extracted from the tracing request, 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.

9. 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 legality 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.

10. A blockchain-based system for the full lifecycle storage and traceability of electronic evidence, characterized in that, include: 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