Blockchain-based electronic evidence archiving and tracing system and method

Abstract

The application discloses a kind of electronic evidence based on blockchain is stored and traced system and method, belong to computer technology field.The method includes: receiving electronic evidence original data, according to evidence type selection difference analysis strategy is carried out information extraction, generates uniform structured data object with global unique identifier;After the normalization pretreatment of uniform structured data object, hash value is calculated;High-precision time is obtained by receiving satellite navigation system signal, time stamp is generated and is digitally signed by time stamp service mechanism;Hash value, time stamp are encapsulated as evidence storage transaction, after being verified by intelligent contract, it is submitted to blockchain network, and is written into distributed ledger by consensus mechanism.The present application can be different for different electronic evidence Differentiated processing, provide high-trust time proof, realize evidence whole-process credible storage and traceability.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, specifically relating to a blockchain-based electronic evidence storage and traceability system and method. Background Technology

[0002] With the rapid development of information technology, electronic evidence such as electronic contracts, instant messaging records, audio and video files, and electronic transfer vouchers are increasingly widely used in judicial, financial, and government fields. Blockchain technology, due to its decentralized, immutable, and traceable characteristics, is gradually becoming an important means of preserving and tracing electronic evidence. However, existing blockchain-based technologies for preserving and tracing electronic evidence still have significant shortcomings, making it difficult to meet the high requirements of judicial practice regarding evidence integrity, reliability, and full-process compliance.

[0003] For example, patent CN116166894B discloses a method for tracing and storing electronic evidence, which generates evidence digests and uses trusted spatiotemporal stamps to achieve project traceability; patent CN119831746B discloses a blockchain parallel evidence storage and traceability method based on DAG, which uses transaction timestamps and hash values ​​for ordering. However, the above-mentioned prior art has the following drawbacks:

[0004] 1. The unified evidence preservation process is used for all types of electronic evidence, but there is a lack of differentiated parsing strategies for different data formats such as electronic contracts, chat logs, audio and video, and transfer vouchers. This makes it easy for key evidence information to be lost or erroneous when extracting it from unstructured files.

[0005] 2. Its timestamps usually rely on the system's local time or network time, which has limited accuracy and is at risk of being tampered with, and cannot provide highly credible proof of existence for traceability to national standard time.

[0006] Therefore, how to provide a blockchain-based evidence storage and traceability system and method that can perform differentiated analysis and unified processing for different types of electronic evidence and generate high-precision and reliable timestamps is an urgent technical problem to be solved. Summary of the Invention

[0007] The purpose of this invention is to provide a blockchain-based electronic evidence storage and traceability system and method, which can effectively solve the technical problems in the prior art such as the ease with which electronic evidence can be tampered with, the difficulty in ensuring its integrity, the difficulty in tracing the source of evidence, the low rate of judicial acceptance, the cumbersome evidence storage process, and the lack of compliance supervision.

[0008] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0009] The first aspect is a blockchain-based method for storing and tracing electronic evidence, which includes the following steps:

[0010] The system receives the original data of electronic evidence to be stored, selects the corresponding parsing strategy from a variety of preset differentiated parsing strategies according to the type of electronic evidence, extracts information, and generates a unified structured data object with a globally unique identifier. The unified structured data object includes an evidence content field, a metadata field, and a signature field.

[0011] Perform normalized preprocessing on the unified structured data object, and use the preprocessed data as input to calculate the hash value of the preprocessed data as a digital fingerprint;

[0012] By receiving signals from the satellite navigation system, a high-precision time synchronized with Coordinated Universal Time is obtained, a timestamp containing the evidence time is generated, and the timestamp containing the evidence time is digitally signed by the timestamp service organization.

[0013] The hash value, the timestamp, and the associated metadata are encapsulated into a notarized transaction, and the notarized transaction is verified for permissions and authenticity through a smart contract.

[0014] The verified evidence-preserving transaction is submitted to the blockchain network, and multiple consensus nodes write the evidence-preserving transaction into the distributed ledger through a consensus mechanism; wherein, multiple evidence-preserving records within a single block are organized in a Merkle tree data structure, and adjacent blocks form a chain structure by referencing the hash value of the previous block header.

[0015] Secondly, a blockchain-based electronic evidence storage and traceability system is used to execute the above methods, including:

[0016] The evidence collection module is configured to receive the original data of electronic evidence to be stored, select the corresponding parsing strategy from a variety of preset differentiated parsing strategies according to the type of electronic evidence, extract information, and generate a unified structured data object with a globally unique identifier. The unified structured data object includes an evidence content field, a metadata field, and a signature field.

[0017] The hash calculation engine is configured to perform normalized preprocessing on the unified structured data object, and use the preprocessed data as input to calculate the hash value of the preprocessed data as a digital fingerprint.

[0018] The high-precision timestamp module is configured to obtain high-precision time synchronized with Coordinated Universal Time by receiving signals from the satellite navigation system, generate a timestamp containing the evidence storage time, and have the timestamp containing the evidence storage time digitally signed by the timestamp service organization.

[0019] The smart contract execution layer is configured to encapsulate the hash value, the timestamp, and the associated metadata into a notarized transaction, and to perform permission verification and authenticity verification on the notarized transaction.

[0020] The underlying blockchain network adopts a distributed architecture, including multiple consensus nodes, configured to write the verified evidence-stored transactions into the distributed ledger through a consensus mechanism; wherein, multiple evidence-stored records within a single block are organized in a Merkle tree data structure, and adjacent blocks form a chain structure by referencing the hash value of the previous block header.

[0021] In summary, this application includes at least one of the following beneficial technical effects:

[0022] 1. By pre-setting multiple differentiated analysis strategies and generating a unified structured data object, this invention can accurately extract information from the original data of different types of electronic evidence, effectively avoid the loss or error of key evidence information, and ensure the integrity of the evidence content and the consistency of the data format.

[0023] 2. This invention obtains high-precision time synchronized with Coordinated Universal Time by receiving signals from satellite navigation systems, and the timestamp is digitally signed by a timestamp service organization, providing electronic evidence with third-party authoritative certification of the evidence's storage time, thereby enhancing the non-repudiation and global traceability of the evidence's time attributes.

[0024] 3. This invention calculates the hash value of the unified structured data object generated by differential parsing after standardized preprocessing, and writes it into the blockchain after verification by a smart contract in combination with a high-precision timestamp, forming a trusted closed loop from evidence collection to on-chain storage, ensuring the integrity of the content, time and identity information of electronic evidence, and improving the automation level of the storage process and the data anti-tampering capability. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the overall scheme of the blockchain-based electronic evidence storage and tracing method of this application;

[0026] Figure 2 This is a schematic diagram of the core principle framework of the smart contract execution layer in this application;

[0027] Figure 3 This is a logical flowchart of the electronic evidence preservation process of this application;

[0028] Figure 4 This is a diagram showing the multi-level interaction between judicial authorities, notary offices, parties involved, and third-party evidence storage platforms in this application;

[0029] Figure 5 This is a flowchart outlining the compliance audit process for the entire lifecycle of electronic evidence in this application.

[0030] Figure 6 This is a schematic diagram of the overall scheme of the blockchain-based electronic evidence storage and traceability system proposed in this application. Detailed Implementation

[0031] To further illustrate the technical means and effects adopted by the present invention to achieve the intended purpose, the following description is provided in conjunction with the appendix. Figure 1-6 The present invention will be described in detail below with reference to preferred embodiments and specific implementations.

[0032] This invention provides a blockchain-based electronic evidence storage and traceability system and method. The system comprises six core components: an evidence collection module, a hash calculation engine, a smart contract execution layer, a blockchain underlying network, a compliance audit module, and an audit report generator. The evidence storage and traceability method based on this system includes six main stages: step S1, evidence collection and preprocessing; step S2, hash calculation and digital signature; step S3, timestamp generation; step S4, smart contract execution; step S5, blockchain storage; and step S6, compliance audit and report generation.

[0033] This system adopts a modular design, with each core module interacting with each other through standardized interfaces. The evidence collection module, serving as the system's data entry point, is responsible for receiving various original electronic evidence data submitted by the parties involved and standardizing its format. The hash calculation engine performs hash operations on the standardized electronic evidence data, generating a digital fingerprint that uniquely identifies the electronic evidence. The smart contract execution layer, as the system's business logic hub, includes three sub-modules: evidence submission contract, access control contract, and authenticity verification contract. It coordinates the collaboration between modules and executes business logic related to evidence preservation. The underlying blockchain network adopts a distributed architecture, using a consensus mechanism to synchronously write evidence data into a distributed ledger composed of multiple nodes, ensuring the immutability and traceability of the data. The compliance audit module conducts compliance supervision over the entire process of electronic evidence collection, preservation, and use, ensuring that each step complies with legal and regulatory requirements. The audit report generator summarizes the judgment results of each compliance inspection unit and generates a compliance audit report that meets legal requirements.

[0034] like Figure 1 As shown, step S1, evidence collection and preprocessing, involves receiving raw electronic evidence data of different types and formats submitted by parties through various terminals. This data is extracted using a defined, unified internal data template and classified parsing, transformed into structured data objects, and assigned globally unique identifiers. Hash calculations are then performed, and the evidence is stored on the blockchain. Specifically, this includes the following sub-steps:

[0035] Step S101: The evidence collection module receives the original electronic evidence data submitted by the parties through the evidence collection terminal. The evidence collection terminal can be a desktop client, a web page, a mobile application, or a dedicated hardware device. After logging in, the parties select the electronic evidence file to be stored and submit it.

[0036] The evidence collection module supports various types of electronic evidence, including electronic contracts, instant messaging chat logs, audio and video files, and electronic transfer vouchers. These electronic evidences have very different original formats. Electronic contracts may be submitted in portable document format, word processing document format, or image format. Instant messaging chat logs may be submitted as database exported files, screenshots, or text files. Audio and video files are mostly in streaming media container format, while electronic transfer vouchers are often in image format or bank electronic receipt format.

[0037] Step S102: In order to unify the processing of multiple formats, this step defines a structured internal data representation format. Each piece of electronic evidence is described as a data object, which consists of three parts: evidence content field, metadata field, and signature field.

[0038] The evidence content field is a string that contains the core content of the electronic evidence, such as contract text, conversation records, or key transaction information; the metadata field is a collection of key-value pairs that stores descriptive information related to the electronic evidence, such as creation time, author, and file size; the signature field is an object reserved for storing the digital signature and timestamp generated later, and is initially empty.

[0039] By defining this data structure, we can unify the data entry point and ensure that all subsequent differential analysis work revolves around the same data structure.

[0040] Step S103: When the evidence type is an electronic contract, the evidence collection module calls the document parsing engine to read the internal structure of the portable document format file and extract three parts of information from it.

[0041] The first part is the document text content, which is the entire text string of the contract body, organized according to the original document structure such as chapter titles; the second part is the signature field, which contains all the digital signature information embedded in the document. For each signature field, the signer's identity, signature algorithm, signature value, and signature time attributes are extracted; the third part is the metadata information, which includes the document's creation time, last modification time, author, application identifier that generated the electronic contract file, and file size.

[0042] After extraction, the evidence collection module reorganizes the above information according to the unified internal data format defined in S102 to generate a structured data representation of the electronic contract.

[0043] Step S104: When the evidence type is instant messaging chat logs, the evidence collection module adopts different extraction strategies based on the source format.

[0044] If the source is a database export file from a communication software, the evidence collection module first parses the database file structure, identifies core data tables such as the message table, user table, and conversation table, and their field definitions. Then, based on the table structure, it selectively extracts the dialogue text, timestamps, and sender identification information. If the source is a screenshot file, the evidence collection module calls an optical character recognition engine to perform text recognition on the screenshot image to extract the dialogue text. At the same time, it prompts the parties involved to manually enter the start and end times of the chat as a supplementary source of timestamp information. If the source is a text file, the evidence collection module parses the text according to preset message parsing rules by recognizing specific delimiters or message headers, and locates and extracts the message sender identification, message sending time, and message content.

[0045] After the extraction is completed, all information is reorganized into a structured data representation of the chat logs, thus flexibly adapting to various submission formats of non-standard evidence such as instant messaging chat logs, ensuring that key information is extracted completely.

[0046] Step S105: When the evidence type is an audio or video file, the evidence collection module first calls the multimedia parsing engine to read the file's container format and encoding format information, and then extracts the metadata information of the audio or video file. The extracted metadata information includes basic attributes such as file name, file size, creation time, duration, encoding format, resolution, frame rate, and audio sampling rate.

[0047] If the audio and video files are generated by a smartphone or professional recording equipment, they may contain a dedicated metadata track. The evidence collection module will further extract descriptive information stored in the track, such as the model of the recording equipment and the GPS coordinates of the shooting location.

[0048] All the extracted information is eventually reassembled into a structured data representation of the audio and video files.

[0049] Step S106: When the evidence type is an electronic transfer voucher, the object being processed is usually an image file. The evidence collection module first preprocesses the image, including image denoising, contrast enhancement, and tilt angle correction, to improve the accuracy of subsequent recognition. After that, the evidence collection module calls the optical character recognition engine to perform text recognition on the preprocessed image and extract key information such as the transferring account, the receiving account, the transfer amount, the transfer time, and the transaction serial number.

[0050] This crucial information is ultimately reconstructed into a structured data representation of electronic transfer vouchers. This step involves extracting structured key factual information from unstructured binary files using multimedia analysis and optical character recognition.

[0051] Step S107: After the above differentiation processing is completed, the evidence collection module generates structured electronic evidence data that conforms to a unified internal data format, and packages the structured electronic evidence data and sends it to the hash calculation engine.

[0052] At the same time, the evidence collection module uses a random number generator to generate a globally unique identifier for electronic evidence. The generation method is to first generate a 128-bit value based on random numbers, and then format the 128-bit value into a string that conforms to the UUID version 4 standard.

[0053] The generated globally unique identifier is used to uniquely refer to this electronic evidence throughout the entire evidence preservation and tracing process, running through the entire process of subsequent storage, auditing and tracing, and becoming the starting point of the evidence preservation and tracing chain.

[0054] Step S2: Hash calculation and digital signature, used to sequentially perform normalization, hash calculation, and digital signature on standardized electronic evidence data, generating an unforgeable digital fingerprint and establishing a cryptographic binding relationship between it and the identity of the parties involved, so that it can be used for integrity verification in subsequent timestamp generation and blockchain evidence storage stages. Specifically, it includes the following sub-steps:

[0055] Step S201: The hash calculation engine receives standardized electronic evidence data from the evidence collection module. The standardized electronic evidence data is a structured data representation generated in step S1, which includes an evidence content field, a metadata field, and a signature field. The hash calculation engine prepares to perform a hash operation on the structured data representation to generate a fixed-length hash value as the digital fingerprint of the electronic evidence.

[0056] Step S202: The hash calculation engine performs preprocessing on the structured representation of standardized electronic evidence data, converting it into a standardized byte sequence. The preprocessing process includes two interconnected steps: standardization and serialization organization.

[0057] In the normalization process, the hash calculation engine converts all character encodings in the structured representation to UTF-8 format and standardizes the date and time representation to Coordinated Universal Time (UTC) ISO 8601 format. For example, "January 1, 2024, 12:00" is uniformly represented as "2024-01-01T12:00:00.000Z". At the same time, it removes whitespace characters in the data that are only used for typesetting and have no semantic impact.

[0058] During the serialization process, the hash calculation engine concatenates the byte fragments corresponding to the evidence content field, metadata field, and signature field into a complete byte sequence in sequence. The byte fragments of the evidence content field are placed first, the byte fragments of the metadata field are in the middle, and the byte fragments of the signature field are placed last. A single-byte field separator 0x1E is inserted between the byte fragments of adjacent fields. For the metadata field, since it is a set of key-value pairs, all keys are first arranged in ascending lexicographical order, and then the byte fragments of each key and its corresponding value are concatenated end to end.

[0059] Through the above preprocessing, electronic evidence with the same semantics is always converted into the same byte sequence, eliminating inconsistencies in hash results caused by format differences or whitespace characters.

[0060] Step S203: The hash calculation engine takes the byte sequence generated in step S202 as the input of the hash function, performs the hash operation, and generates a 256-bit hash value.

[0061] In a preferred embodiment, the hash calculation engine uses the secure hash algorithm SHA-256, which converts input data of arbitrary length into fixed 256-bit output data. When it is necessary to meet domestic cryptographic compliance requirements, the hash calculation engine switches to the national cryptographic hash algorithm SM3, which also converts input data of arbitrary length into fixed 256-bit output data.

[0062] Step S204: The 256-bit hash value generated by the hash operation has four characteristics, specifically:

[0063] Certainty means that the same electronic evidence data will always yield the same result after multiple hash calculations.

[0064] Irreversibility, meaning that the original electronic evidence data cannot be derived from the hash value alone;

[0065] Collision resistance, meaning the probability of finding two different pieces of electronic evidence data that produce the same hash value is extremely low;

[0066] Sensitivity means that any tiny change in the electronic evidence data will cause the hash value to change.

[0067] These characteristics together ensure that the hash value can effectively represent the integrity status of electronic evidence data. Any tampering with electronic evidence data will be directly reflected in the change of hash value, thus providing a reliable basis for subsequent authenticity verification.

[0068] Step S205: After the hash calculation is completed, the smart contract execution layer receives the 256-bit hash value output by the hash calculation engine, and performs a digital signature operation on the hash value using an asymmetric encryption algorithm to generate a digital signature value that is bound to the electronic evidence.

[0069] The digital signature process uses the party's private key to encrypt the hash value. Let the hash value be... The private key of the party concerned is The signature generation function defined using an asymmetric encryption algorithm is: Then the digital signature value The calculation expression is:

[0070]

[0071] in It is a 256-bit binary sequence. The private key generated for the asymmetric encryption algorithm. The signature generation function specified for the selected algorithm. The digital signature value is calculated and output; digital signature value An unforgeable binding relationship is formed between the electronic evidence and the digital evidence, which is used for subsequent identity authentication and signature verification.

[0072] In a preferred embodiment, when adopting international standards, the smart contract execution layer uses the RSA-2048 algorithm for digital signatures with a key length of 2048 bits; when domestic cryptographic compliance requirements need to be met, the smart contract execution layer uses the national cryptographic SM2 algorithm for digital signatures, which is based on elliptic curve cryptography theory.

[0073] Step S206, the specific execution process of digital signature consists of three stages.

[0074] First, the smart contract execution layer retrieves the party's digital certificate from the digital certificate repository. The digital certificate is issued by an authoritative certificate authority and contains the party's public key and identity information.

[0075] Then, the smart contract execution layer calls the private key of the party concerned to perform encryption operation on the hash value generated in step S204. The specific algorithm of the encryption operation depends on the type of asymmetric encryption algorithm selected in step S205, and generates a digital signature value.

[0076] Finally, the smart contract execution layer associates and stores the digital signature value with the globally unique identifier of the electronic evidence and the digital certificate identifier of the parties involved, establishing a binding relationship between the digital signature and the electronic evidence. This cryptographically binds the identity of the parties involved with the hash value of the electronic evidence, allowing any party to verify the authenticity of the signature and the integrity of the evidence through the public key.

[0077] Step S207: After the digital signature is generated, the smart contract execution layer can verify the integrity of the electronic evidence and the authenticity of the signer's identity at any time based on the verification request.

[0078] During verification, the digital signature value is first decrypted using the party's public key. Let the digital signature value be... The public key of the party concerned is The signature verification function defined using an asymmetric encryption algorithm is: The hash value recovered after decryption The calculation expression is:

[0079]

[0080] in The digital signature value generated in step S205, For the private key The public keys of the paired parties, The signature verification function specified for the selected algorithm. To decrypt and recover the hash value.

[0081] Then recalculate the hash value of the current electronic evidence data. ,Will and Perform bit-by-bit comparison; if Confirm that the electronic evidence has not been tampered with and was indeed signed by the party submitting the evidence; if The court determined that the electronic evidence may have been tampered with or the signature may be invalid.

[0082] Through the above verification mechanism, the integrity of electronic evidence and the authenticity of the signatory's identity can still be verified after the evidence has been stored.

[0083] Step S3: Timestamp Generation. This step receives the hash value and digital signature generated in Step S2. It acquires high-precision time synchronized with Coordinated Universal Time (UTC) by capturing satellite signals from the BeiDou Navigation Satellite System or Global Positioning System, generates a timestamp signed by an authoritative institution, and encapsulates all data items into a standardized evidence storage data message to establish the non-repudiable temporal attribute of the electronic evidence. Specifically, it includes the following sub-steps:

[0084] Step S301: The high-precision timestamp module receives the electronic evidence hash value and digital signature from step S2, and prepares to generate a storage timestamp for the electronic evidence. The timestamp is used to prove that the electronic evidence existed at a specific point in time, providing a credible third-party proof of the time attribute of the evidence.

[0085] Step S302: The satellite signal receiving unit of the high-precision timestamp module continuously receives satellite signals from the BeiDou Navigation Satellite System or the Global Positioning System. The BeiDou Navigation Satellite System provides positioning, navigation and timing services with timing accuracy at the nanosecond level, and the Global Positioning System also provides positioning, navigation and timing services with timing accuracy at the nanosecond level.

[0086] The signal receiving unit uses signal processing algorithms to calculate Coordinated Universal Time (UTC) based on the onboard atomic clock time carried in the satellite signal and the signal propagation delay. Simultaneously read the current reading of the local clock. ,according to Calculate the deviation of local time from Coordinated Universal Time. Then according to Generate high-precision time values ​​synchronized with Coordinated Universal Time. ; It is accurate to the millisecond and includes time components such as year, month, day, hour, minute, second, and millisecond, thus establishing a precise time for the preservation of electronic evidence with nanosecond-level timekeeping accuracy.

[0087] Step S303: The high-precision timestamp module will generate the high-precision time value in step S302. The data is assembled into timestamp information, which includes the evidence storage time accurate to milliseconds in Coordinated Universal Time, time zone information identifying the time zone offset corresponding to the evidence storage time, and a timestamp signature generated by the timestamp service provider using its private key to digitally sign the evidence storage time and time zone information.

[0088] Let the time zone offset be The private key of the timestamp service provider is The signature generation function defined using the digital signature algorithm is: Then timestamp signature according to Calculation generated; where For high-precision time values, This is the time zone offset corresponding to the evidence storage time. For the private key of the timestamp service provider, The signature generation function specified for the selected digital signature algorithm. This indicates that the time value and offset are concatenated to form the data to be signed. This is used to calculate the output timestamp signature. The timestamp service provider uses the RSA-2048 algorithm or the Chinese national cryptographic algorithm SM2 to generate the timestamp signature. Any third party can verify whether the timestamp information has been tampered with using the timestamp service provider's public key.

[0089] Based on this, the high-precision timestamp module obtains the digital certificate of the timestamp service provider. The digital certificate of the timestamp service provider is issued by an authoritative certificate authority and contains the public key and organizational identity information of the timestamp service provider. The high-precision timestamp module associates and stores the digital certificate of the timestamp service provider with the timestamp information as a verifiable credential of the legal qualification of the timestamp service provider.

[0090] Step S304: The high-precision timestamp module encapsulates the timestamp information together with the electronic evidence hash value and digital signature received in step S301 into a storage data message.

[0091] The structure of the evidence storage data message is defined using the Protocol Buffers format or Extensible Markup Language format, and includes five fields: Evidence Unique Identifier, Hash Value, Digital Signature, Timestamp, and Timestamp Signature. The Evidence Unique Identifier field stores the globally unique identifier of the electronic evidence, the Hash Value field stores the 256-bit hash value of the electronic evidence, the Digital Signature field stores the digital signature value of the parties involved, the Timestamp field stores the high-precision timestamp information generated in step S303, and the Timestamp Signature field stores the digital signature of the timestamp service provider.

[0092] Through the above encapsulation, the evidence identification, integrity verification data, signer identity binding data, and authoritative time data are aggregated into a self-contained evidence storage data unit.

[0093] Step S305: The high-precision timestamp module sends the encapsulated evidence storage data message to the smart contract execution layer to enter the subsequent evidence storage process, completing the connection from timestamp generation to smart contract execution, so that the evidence storage data message carries complete time proof to enter the permission verification and authenticity verification stage.

[0094] Step S4: The smart contract executes, receiving the evidence storage data message encapsulated in Step S3. It sequentially triggers three procedures: evidence submission, permission verification, and authenticity verification. After confirming that the submitter has the necessary permissions and that the electronic evidence has not been previously stored, the smart contract releases the evidence storage data message to the blockchain evidence storage process and provides on-chain hash comparison capabilities during evidence retrieval. Specifically, it includes the following sub-steps:

[0095] Step S401: The smart contract execution layer, as the central hub of the evidence storage business logic, contains three sub-modules: evidence submission contract, access control contract, and authenticity verification contract. These sub-modules exchange evidence storage data messages and verification results through standardized interfaces, such as... Figure 2 As shown.

[0096] The evidence submission contract first receives the evidence storage data message from step S305, and parses out the evidence type field and the submitter identity information field from the evidence storage data message. The value of the evidence type field is used to select the corresponding inspection rule according to the evidence category in the subsequent compliance audit stage, and is written to the operation log for classification and statistics. The value of the submitter identity information field is passed to the permission control contract for permission verification, and is also written to the operation log for behavior tracing.

[0097] Step S402: After the evidence submission contract is parsed, an evidence submission event is generated. The evidence submission event triggers the step-by-step flow of the evidence preservation process within the smart contract execution layer. At the same time, the evidence submission contract sends the reference information of the evidence preservation data message to the permission control contract, requesting verification of the submitter's operation permission. Thus, the control is transferred from the evidence receiving stage to the permission verification stage in an event-driven manner.

[0098] Step S403: After receiving the permission verification request, the permission control contract extracts the submitter's identity identifier and the type of operation to be performed from the request, and then queries the user role mapping table based on the identity identifier to determine the role category to which the submitter belongs.

[0099] The user role mapping table is a key-value pair structure, where the key is the identity identifier and the value is the role identifier. The encoding and meaning of the role identifiers are as follows: JUDICIARY represents judicial organs, NOTARY represents notary offices, PARTY represents parties involved, and PLATFORM represents third-party evidence storage platforms. The user role mapping table is pre-written with corresponding records by the system administrator during user registration. The role access control mechanism divides system users into the above four levels of subjects, and each level of subject corresponds to a different set of operation permissions in the role permission matrix.

[0100] Step S404: The access control contract queries the role access matrix based on the role category and operation type determined in step S403 to determine whether the submitter has the authority to perform the evidence submission operation.

[0101] The role permission matrix is ​​a two-dimensional structure. The rows are role identifiers and the columns are operation types. The values ​​of the matrix cells are allowed or denied. When querying, the role identifier is used to locate the row in the matrix, the operation type is used to locate the column in the matrix, and the value of the cell at the intersection of the row and column is read as the judgment result.

[0102] The initial configuration of the role permission matrix is ​​as follows: the judicial organ row is allowed in the columns of obtaining evidence, verifying the authenticity of evidence, and issuing judicial appraisal opinions; the notary office row is allowed in the columns of verifying evidence, issuing notarized documents, and conducting notarization and authentication; the parties row is allowed in the columns of submitting evidence, viewing the evidence they have submitted, and applying for evidence verification; the third-party evidence storage platform row is allowed in the columns of receiving evidence storage requests, providing evidence query services, and conducting evidence preservation; and all other columns in each row are set to denied.

[0103] Step S405: The permission control contract generates a corresponding response message based on the permission verification result.

[0104] If the verification passes, the access control contract sends the evidence storage data message to the authenticity verification contract to enter the authenticity verification stage; if the verification fails, the access control contract rejects the evidence storage request, returns an insufficient permission error message to the submitter containing the error code, error description and solution suggestions, and writes the submitter's identity identifier, operation type, error code and error time to the exception operation log.

[0105] Through the above mechanism, unauthorized operations are intercepted at the evidence storage entry point, and only entities with legal authority are allowed to submit evidence. The abstract four-level entity permission model is implemented as an automatically executable access control judgment through two-level queries of user role mapping table and role permission matrix.

[0106] Step S406: After the permission verification is passed, the authenticity verification contract receives the evidence storage data message, extracts the 256-bit hash value of the electronic evidence, and sends a historical hash query request to the underlying blockchain network to query whether the same hash value record already exists in the distributed ledger.

[0107] If the query result is empty, it indicates that the electronic evidence has not been stored. The authenticity verification contract generates a verification pass message, allowing the stored data message to enter the blockchain storage process in the subsequent step S5. If the query result is not empty, it indicates that the electronic evidence has been stored. The authenticity verification contract generates a verification failure message, writes the globally unique identifier of the evidence, the duplicate hash value, and the duplicate submission alarm information into the abnormal operation log and prompts the submitter.

[0108] Through the above mechanism, deduplication verification is completed before data is uploaded to the blockchain to prevent the same electronic evidence from being stored repeatedly.

[0109] Step S407: In the evidence retrieval scenario, the authenticity verification contract receives an evidence retrieval request from a judicial authority or notary office, obtains the on-chain hash value recorded during evidence storage from the distributed ledger of the underlying blockchain network, and compares the on-chain hash value with the current electronic evidence hash value carried in the retrieval request bit by bit.

[0110] If the two hash values ​​match, it means that the retrieved electronic evidence is consistent with the original data at the time of notarization, and the authenticity verification contract generates a verification pass message; if the two hash values ​​do not match, it means that the retrieved electronic evidence may have been tampered with after notarization, and the authenticity verification contract generates a tampering risk warning message containing a globally unique identifier for the evidence, the on-chain hash value, the current hash value, and an inconsistency assessment, and writes the warning information to the abnormal operation log.

[0111] Through the above mechanism, the party obtaining the evidence is provided with verifiable proof of its integrity, and tampering can be detected and traced immediately.

[0112] like Figure 3As shown, step S5: Blockchain notarization, used to receive notarization transaction requests verified by the smart contract execution layer in step S4. After the distributed network nodes reach a consensus on the transaction order and status through the consensus mechanism, the hash value, timestamp, and participating entity information of the electronic evidence are written into a distributed ledger organized with a Merkle tree, realizing the immutable storage and traceable query of the evidence. Specifically, it includes the following sub-steps:

[0113] Step S501: The underlying blockchain network receives a notarization transaction request from the smart contract execution layer in step S4. The notarization transaction request includes a transaction identifier field, an evidence hash value field, a timestamp field, a participant information field, and a digital signature field.

[0114] The transaction identifier field is generated by the initiating node and its value follows a globally unique identifier format, uniquely identifying this evidence storage transaction across the entire network; the evidence hash value field stores the 256-bit hash value of the electronic evidence; the timestamp field stores the high-precision timestamp information generated in step S3; the participant information field stores the submitter's identity and evidence type; and the digital signature field stores the digital signature of the smart contract execution layer on the aforementioned four fields. The signing method involves concatenating the byte fragments corresponding to the transaction identifier field, evidence hash value field, timestamp field, and participant information field in this order, and then signing them using the private key of the smart contract execution layer.

[0115] Step S502: The underlying blockchain network adopts a distributed architecture, consisting of multiple interconnected nodes. Each node stores a complete copy of the distributed ledger, and the nodes synchronize data through a peer-to-peer communication protocol to ensure the consistency of the ledger data of each node.

[0116] When a node receives the evidence storage transaction request in step S501, the receiving node broadcasts the evidence storage transaction request to other nodes in the network, thereby forming a redundant distribution of transaction information among nodes, so that the failure or exit of any single node does not affect the propagation and processing of the evidence storage transaction request.

[0117] Step S503: The consensus mechanism module receives the evidence storage transaction request broadcast to this node and first performs format verification and digital signature verification on the evidence storage transaction request.

[0118] The format verification checks whether the transaction identifier field, evidence hash value field, timestamp field, participant information field, and digital signature field are complete and conform to the predetermined structure of the protocol buffer format or Extensible Markup Language format. During digital signature verification, the transaction identifier field, evidence hash value field, timestamp field, and participant information field in the evidence storage transaction request are concatenated into the data to be verified in the order agreed upon by S501. The public key of the smart contract execution layer is used to decrypt the digital signature field to obtain the reference hash value. At the same time, the hash value of the data to be verified is recalculated. The recalculated hash value is compared with the reference hash value. If the two match, the signature verification is successful.

[0119] After successful verification, the consensus mechanism module places the evidence storage transaction request into the pending transaction pool to wait for it to enter the consensus process. Before the transaction enters the pool, it performs a legality screening to prevent evidence storage transaction requests with abnormal formats or invalid signatures from occupying consensus resources.

[0120] Step S504: The consensus mechanism module selects and executes a consensus algorithm based on the configuration of the underlying blockchain network, and reaches an agreement with other nodes in the network on the transaction order and state.

[0121] The underlying blockchain network supports three consensus algorithms to adapt to different deployment scenarios. When the underlying blockchain network is deployed as a public chain, the Proof-of-Work consensus algorithm is used, where nodes compete for the right to record transactions by completing a hash problem, and only nodes that control more than half of the total network computing power can manipulate the transaction order. When the underlying blockchain network is deployed as a consortium chain, the Proof-of-Stake consensus algorithm is used, which allocates the right to record transactions based on the number of tokens held by nodes and the time they have held, in order to reduce energy consumption and operating costs. When the underlying blockchain network is deployed as a consortium chain with high requirements for transaction finality, the Practical Byzantine Fault Tolerance consensus algorithm is used, which reaches consensus through multiple rounds of voting even if there are no more than one-third of malicious nodes.

[0122] Through the aforementioned configurable consensus mechanism, the underlying blockchain network can complete distributed consensus confirmation of notarized transactions in both public and consortium blockchain deployment scenarios.

[0123] Step S505: After consensus is reached, each node writes the notarized transaction confirmed by consensus into a new block in its local ledger and broadcasts the new block to other nodes in the network. After receiving the new block, each node independently verifies the legality of the transactions in the new block and the correctness of the hash reference of the new block. After verification, it returns a confirmation message to the initiating node, completing the final confirmation of the notarized transaction.

[0124] Step S506: The distributed ledger permanently stores the evidence records of electronic evidence in blocks. Each evidence record contains the evidence hash value, timestamp, participating entity information, and block height.

[0125] Distributed ledgers use a Merkle tree data structure to organize all stored records within a single block. The construction process is as follows: Each stored record has its hash value calculated to become a leaf node of the Merkle tree. Then, the hash values ​​of two adjacent leaf nodes are concatenated and the hash value is calculated again to generate the parent node. This process is repeated layer by layer upwards until a unique Merkle root hash value is generated. Let the... The hash value of the evidence record is , No. The hash value of the evidence record is If the two are adjacent nodes at the same level, then the hash value of the parent node is... The calculation expression is:

[0126]

[0127] in and The hash values ​​of two adjacent nodes at the same level. This means concatenating two hash values ​​to form the data to be hashed. The hash function selected in step S203; if the number of nodes in the current layer is odd, the last node is directly promoted to the next layer to continue participating in the merging; this process is repeated layer by layer, and the final generated single hash value is the Merkle hash value. Any alteration to the evidence record will change the hash value of the corresponding leaf node, and this will propagate layer by layer, leading to... The change is thus detected.

[0128] At the same time, the block header of each block contains the hash value of the block header of the previous block as a hash reference, forming a chain-like structure between blocks. Let the first block be... The block header hash value of each block is Then the first The block header of each block records the preceding hash reference as follows: ,Right now The generation depends on .

[0129] This creates a dual tamper-proof mechanism using Merkle trees and chained hash references. Tampering with any historical record will affect the Merkle root hash value of the block. This changes and causes the hash references of all subsequent blocks to become invalid.

[0130] like Figure 5 As shown, step S6: Compliance Audit and Report Generation, is used to check the compliance of electronic evidence in the three stages of collection, storage, and use, summarize the judgment results of each inspection unit, and generate a digitally signed compliance audit report, ensuring that the entire process is traceable and complies with legal and regulatory requirements. Specifically, it includes the following sub-steps:

[0131] Step S601: The compliance audit module initiates compliance supervision of the entire process of electronic evidence. The compliance audit module contains three sub-units: collection compliance check unit, evidence storage compliance check unit, and usage compliance check unit. The three sub-units correspond to the compliance verification tasks of the collection stage, evidence storage stage, and usage stage, respectively.

[0132] Step S602: The compliance inspection unit extracts signature-related fields such as digital signature value, signature algorithm identifier, and signature time from the structured data representation of electronic evidence, and calls the electronic signature verification service to verify the digital signature.

[0133] The electronic signature verification service verifies each item according to the legal requirements for a reliable electronic signature as stipulated in the Electronic Signature Law. The verification content includes: a unique correspondence between the signature data and the signer; the signature private key is exclusive to the signer and controlled only by the signer; the signing act is performed by the signer or authorized by the signer; the signer cannot deny the signing act after the signature is completed; the digital signature value can be clearly distinguished from the original data; and the electronic evidence data has not been tampered with after the signature.

[0134] After all the above checks are passed, the electronic evidence is confirmed to meet the requirements for reliable electronic signatures.

[0135] Step S603: The compliance inspection unit simultaneously calls the identity authentication service to verify the identity information of the signer, confirm whether the identity of the signer is authentic and credible, and verify whether the formation time of the electronic evidence is within a reasonable range. The reasonableness judgment criteria for the formation time are: the formation time is not later than the evidence storage timestamp and not earlier than the start time of the validity period of the signer's digital certificate.

[0136] After the above verification is completed, the compliance inspection unit generates a compliance judgment conclusion based on the electronic signature verification result, identity verification result, and formation time verification result. When the compliance judgment conclusion is passed, it means that the three items of electronic signature legality, signer identity authenticity, and evidence formation time reasonableness in the collection stage all meet the requirements. When the compliance judgment conclusion is failed, the inspection items that failed and the reasons are listed one by one.

[0137] Step S604: The evidence storage compliance inspection unit extracts timestamp information from the evidence storage data message, calls the timestamp verification service, and verifies whether the timestamp format conforms to the ISO 8601 standard, whether the time accuracy reaches the millisecond level, and whether the timestamp signature is issued by a legitimate timestamp service provider. The timestamp verification service verifies the timestamp signature field using the public key of the timestamp service provider, and at the same time checks whether the digital certificate of the timestamp service provider is valid and has not been revoked.

[0138] At the same time, the evidence preservation compliance inspection unit extracts the identity information of the entities participating in the evidence preservation process from the evidence preservation data message and calls the identity authentication service to verify whether the entities participating in the evidence preservation process have legitimate identity authentication.

[0139] In step S605, the evidence preservation compliance inspection unit further obtains the intermediate results and parameter configurations in the hash calculation process from the hash calculation engine. The intermediate results include the normalized byte sequence generated in step S202, the hash algorithm identifier selected in step S203, and the 256-bit hash value calculated and output in step S203. The evidence preservation compliance inspection unit re-executes the hash calculation with the obtained normalized byte sequence and hash algorithm identifier, and compares the recalculated hash value with the 256-bit hash value in the intermediate results to verify whether the hash calculation result is correct.

[0140] Then, the evidence preservation compliance inspection unit obtains the consensus process record of the evidence preservation transaction from the underlying blockchain network. The consensus process record includes the consensus algorithm type selected in step S504, the number of nodes participating in the consensus, the voting records of each node, and the final block height to which consensus is reached. The evidence preservation compliance inspection unit verifies whether the voting ratio of each node in the consensus process record reaches the confirmation threshold required by the selected consensus algorithm.

[0141] After the above verification is completed, the evidence storage compliance inspection unit generates an evidence storage compliance judgment conclusion based on the timestamp verification result, the subject identity verification result, the hash calculation verification result, and the consensus process verification result. When the evidence storage compliance judgment conclusion is passed, it means that the four items of timestamp standardization, subject identity legality, hash calculation correctness, and on-chain process compliance in the evidence storage process all meet the requirements. When the evidence storage compliance judgment conclusion is failed, the failed inspection items and reasons are listed one by one.

[0142] Step S606: Use the compliance check unit to receive evidence usage requests from external systems. Evidence usage requests include evidence retrieval requests, evidence viewing requests, and evidence export requests. Use the compliance check unit to extract the requester's identity identifier and the type of operation to be performed from the evidence usage request, call the permission control contract to query the role permission matrix, and verify whether the requester has the corresponding permission to perform evidence retrieval, evidence viewing, or evidence export operations.

[0143] Step S607: The compliance check unit decides to execute the corresponding operation or reject the operation request based on the permission verification result. Regardless of whether the operation is executed, the compliance check unit records the operation time, operator identity identifier, operation type and operation result in the operation log of the read-only storage area in an append-only write manner. The storage area where the operation log is located is configured to be unmodifiable after being written once. In this way, the operation authorization verification and the tamper-proof recording of the entire operation log are completed in the usage phase.

[0144] In step S608, the audit report generator sequentially requests compliance judgment conclusions from the collection compliance inspection unit, the evidence storage compliance inspection unit, and the usage compliance inspection unit. It then assembles these three judgment conclusions, along with the globally unique identifier of the electronic evidence, evidence type, submitter's identity information, evidence storage time, time zone information, timestamp signature, hash algorithm type, 256-bit hash value, and hash verification conclusion, according to a preset audit report template to generate a complete compliance audit report. The hash verification conclusion originates from the comparison result generated by the evidence storage compliance inspection unit in step S605 when verifying the hash calculation result.

[0145] Step S609: The audit report generator stores the generated compliance audit report in a portable document format and digitally signs the compliance audit report using the audit report generator's private key. The signature algorithm adopts the RSA-2048 algorithm or the national cryptographic SM2 algorithm, thereby making the compliance audit report itself verifiable in terms of authenticity and integrity. Any tampering with the content of the audit report can be detected through the public key verification operation of the audit report generator.

[0146] like Figure 4 As shown, after completing the entire process of evidence storage and auditing from steps S1 to S6, this embodiment provides evidence retrieval, verification and query services to multiple entities such as judicial organs, notary offices, parties and mediation institutions. At the same time, it has built-in automatic processing mechanisms for three types of situations: abnormal permissions, data tampering and consensus failure.

[0147] The judicial authorities first verify their identity through the access control contract. The access control contract confirms that the judicial authorities have the operational authority to retrieve evidence based on the role and access matrix. After the verification is successful, the judicial authorities initiate an evidence retrieval request to the underlying blockchain network, and the request carries the globally unique identifier of the electronic evidence.

[0148] The underlying blockchain network uses a globally unique identifier to query the 256-bit hash value, high-precision timestamp, and participating entity information recorded during evidence storage in the distributed ledger, and returns the query results to the judicial authorities.

[0149] The authenticity verification contract then verifies the authenticity of the retrieved electronic evidence by comparing the hash value stored on the chain with the hash value recalculated from the current electronic evidence bit by bit, generating a verification report. The verification report includes the storage time of the electronic evidence, the hash value comparison result, and the compliance judgment conclusion. Judges can use the verification report as a reference for determining the authenticity of the evidence.

[0150] The notary office submits a verification request through the interface provided in this embodiment. The verification request carries a globally unique identifier for the electronic evidence to be verified.

[0151] In this embodiment, on-chain evidence information is extracted from the distributed ledger of the underlying blockchain network according to the verification request. The on-chain evidence information includes the globally unique identifier of the electronic evidence, the evidence type, the evidence timestamp, the 256-bit hash value, and the compliance judgment conclusions of each stage. In this embodiment, the above-mentioned on-chain evidence information is assembled into a verification result certificate and returned to the notary office. The notary office issues a notarial certificate based on the verification result certificate, providing third-party notarization and authentication services for electronic evidence.

[0152] The parties or mediation institutions can use this embodiment to query the complete evidence storage record of electronic evidence. The complete evidence storage record includes information such as the time of evidence generation, the time of submission, and the actions of each party in the evidence storage process. The above information provides objective and credible evidence support for dispute mediation, helping mediators to quickly ascertain the facts and resolve conflicts.

[0153] When the access control contract detects that the submitter does not have the authority to submit evidence, the smart contract execution layer automatically rejects the evidence submission request and returns an error message indicating insufficient permissions to the submitter. The error message includes the error code, error description, and solution suggestions, making it easier for the submitter to understand the cause of the problem and make corrections. At the same time, the smart contract execution layer writes the requester's identity identifier, operation type, error code, and error time into the exception operation log for subsequent problem tracking and auditing.

[0154] When the authenticity verification contract detects that the on-chain hash value stored in the underlying blockchain network is inconsistent with the hash value recalculated from the current electronic evidence, the smart contract execution layer automatically determines that the electronic evidence may have been tampered with and generates a tampering risk warning. The tampering risk warning information includes the globally unique identifier of the electronic evidence, the on-chain hash value, the current hash value, the inconsistency assessment, and the risk level. The smart contract execution layer sends a warning notification to relevant parties, and the notification methods include push notifications and emails as described in this embodiment.

[0155] When the consensus mechanism of the underlying blockchain network fails to reach an agreement on the notarization transaction within a preset time, the smart contract execution layer automatically triggers the retry mechanism. The smart contract execution layer first waits for a preset cooldown time, and after the cooldown time ends, it re-initiates the notarization transaction request to the underlying blockchain network. The maximum number of retries is set to 3.

[0156] If all three retries fail, this embodiment records the fault information, which includes the transaction identifier, failure time, failure reason, and number of retries. An alarm notification is then sent to the administrator, which includes the current status of the underlying blockchain network, fault details, and suggested handling measures to facilitate timely intervention by the administrator.

[0157] In summary, this embodiment, through the aforementioned application scenarios and anomaly handling mechanisms, provides a complete service-oriented presentation of the evidence preservation and traceability capabilities constructed in steps S1 to S6 to actual users such as judicial organs, notary offices, and parties involved. Evidence retrieval, verification, and query operations all rely on the immutable hash values, timestamps, and compliance audit conclusions in the blockchain distributed ledger. There are corresponding automatic detection and handling paths for the three types of anomalies: permission abnormalities, data tampering, and consensus failures. This makes this embodiment verifiable in completeness and operable in reliability in judicial practice.

[0158] like Figure 6 As shown, based on the above method, the present invention also provides a blockchain-based electronic evidence storage and traceability system, comprising:

[0159] The evidence collection module is used to receive the original data of electronic evidence to be stored, select the corresponding parsing strategy from a variety of preset differentiated parsing strategies according to the type of electronic evidence, extract information, and generate a unified structured data object with a globally unique identifier. This unified structured data object includes an evidence content field, a metadata field, and a signature field.

[0160] The hash calculation engine is used to perform normalized preprocessing on the unified structured data objects generated by the evidence collection module, and to calculate the hash value of the preprocessed data as a digital fingerprint.

[0161] The high-precision timestamp module is used to obtain high-precision time synchronized with Coordinated Universal Time by receiving signals from the satellite navigation system, generate a timestamp containing the storage time, and have the timestamp service organization digitally sign the timestamp.

[0162] The smart contract execution layer is used to encapsulate the hash value output by the hash calculation engine, the timestamp generated by the high-precision timestamp module, and the associated metadata into a notarized transaction, and to perform permission verification and authenticity verification on the notarized transaction.

[0163] The underlying blockchain network adopts a distributed architecture, including multiple consensus nodes, which are used to write the notarized transactions verified by the smart contract execution layer into the distributed ledger through a consensus mechanism. Among them, multiple notarized records within a single block are organized in a Merkle tree data structure, and adjacent blocks form a chain structure by referencing the hash value of the previous block header.

[0164] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention. Therefore, the embodiments should be regarded as exemplary and non-limiting in all respects.

[0165] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment includes only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A blockchain-based method for storing and tracing electronic evidence, characterized in that: Includes the following steps: The system receives the original data of electronic evidence to be stored, selects the corresponding parsing strategy from a variety of preset differentiated parsing strategies according to the type of electronic evidence, extracts information, and generates a unified structured data object with a globally unique identifier. The unified structured data object includes an evidence content field, a metadata field, and a signature field. Perform normalized preprocessing on the unified structured data object, and use the preprocessed data as input to calculate the hash value of the preprocessed data as a digital fingerprint; By receiving signals from the satellite navigation system, a high-precision time synchronized with Coordinated Universal Time is obtained, a timestamp containing the evidence time is generated, and the timestamp containing the evidence time is digitally signed by the timestamp service organization. The hash value, the timestamp, and the associated metadata are encapsulated into a notarized transaction, and the notarized transaction is verified for permissions and authenticity through a smart contract. The verified evidence-preserving transaction is submitted to the blockchain network, and multiple consensus nodes write the evidence-preserving transaction into the distributed ledger through a consensus mechanism; wherein, multiple evidence-preserving records within a single block are organized in a Merkle tree data structure, and adjacent blocks form a chain structure by referencing the hash value of the previous block header.

2. The method for storing and tracing electronic evidence based on blockchain according to claim 1, characterized in that, The preset multiple differential parsing strategies include: For electronic contracts, the document parsing engine is invoked to extract the contract text content, signature field information, and document metadata; For each type of instant messaging chat history, the system selects database parsing, optical character recognition, or preset message parsing rules to extract the conversation content, timestamp, and sender information based on the source file format. For audio and video file types, the multimedia parsing engine is called to extract the file container format, encoding format, and embedded metadata information; For electronic transfer voucher types, the image file is preprocessed and then the optical character recognition engine is called to extract key transaction information.

3. The method for storing and tracing electronic evidence based on blockchain according to claim 1, characterized in that, The process of obtaining high-precision time synchronized with Coordinated Universal Time by receiving signals from a satellite navigation system, generating a timestamp containing the evidence time, and having the timestamp service organization digitally sign the timestamp containing the evidence time, specifically includes: The satellite signal receiving unit continuously receives satellite signals from the BeiDou Navigation Satellite System or the Global Positioning System, calculates Coordinated Universal Time (UTC) based on the satellite signals, and generates a high-precision time value synchronized with UTC. The high-precision time values ​​are assembled into timestamp information, which includes the evidence storage time expressed in Coordinated Universal Time and time zone information; The timestamp service provider is invoked to digitally sign the evidence storage time and the time zone information using the private key of the timestamp service provider, thereby generating a timestamp signature.

4. The method for storing and tracing electronic evidence based on blockchain according to claim 1, characterized in that, The multiple evidence records within a single block are organized using a Merkle tree data structure, including: Calculate the hash value of each evidence record in the block and use it as the leaf node of the Merkle tree; The hash values ​​of two adjacent leaf nodes are concatenated and the hash value is calculated again to generate the parent node. This process is repeated layer by layer until a unique Merkle root hash value is generated. If the number of nodes in the current layer is odd, promote the last node directly to the next layer. The adjacent blocks form a chain structure by referencing the hash value of the previous block header. Specifically, the block header of the current block contains the hash value of the previous block header as a hash reference.

5. The method for storing and tracing electronic evidence based on blockchain according to claim 1, characterized in that, The process of encapsulating the hash value, the timestamp, and associated metadata into a notarized transaction, and then using a smart contract to verify the permissions and authenticity of the notarized transaction, includes: The evidence storage transaction is encapsulated into a transaction data structure that includes a transaction identifier field, an evidence hash value field, a timestamp field, a participant information field, and a digital signature field; The permission control contract in the smart contract execution layer is invoked to query the role permission matrix based on the submitter's role category and determine whether the submitter has the permission to perform the evidence storage operation. After the permission verification is passed, the authenticity verification contract in the smart contract execution layer is invoked to send a historical hash query request to the underlying blockchain network to confirm whether the hash value has been stored.

6. The method for storing and tracing electronic evidence based on blockchain according to claim 1, characterized in that, The process of multiple consensus nodes writing the notarized transaction into the distributed ledger through a consensus mechanism includes: The consensus node performs format verification and digital signature verification on the received evidence-stored transactions; Once the verification is successful, the evidence-stored transaction will be placed in the pending confirmation transaction pool. Based on the consensus algorithm configured in the underlying blockchain network, it reaches an agreement with other nodes in the network on the order and state of transactions; Once a consensus is reached, each node will write the notarized transaction confirmed by the consensus into a new block in its local ledger and broadcast the new block to other nodes in the network.

7. The method for storing and tracing electronic evidence based on blockchain according to claim 1, characterized in that, The normalization preprocessing of the unified structured data object specifically includes: Convert all character encodings to UTF-8 format; Standardize all date and time representations to the ISO 8601 format; Remove whitespace characters from the data that are only used for typesetting and have no semantic impact; The byte fragments corresponding to the evidence content field, the metadata field, and the signature field are concatenated in order, and a single-byte field separator 0x1E is inserted between the byte fragments of adjacent fields. For the metadata field, after arranging the key-value pairs in the metadata field in ascending lexicographical order of the keys, the byte fragments of each key and the corresponding value of each key are concatenated end to end.

8. The method for storing and tracing electronic evidence based on blockchain according to claim 1, characterized in that, The generation of a unified structured data object with a globally unique identifier specifically includes: A 128-bit random value is generated using a random number generator, and the 128-bit random value is formatted into a string that conforms to the UUID version 4 standard as a globally unique identifier. The core content of electronic evidence is stored in the evidence content field, descriptive information is stored in the metadata field in the form of a set of key-value pairs, and the signature field is reserved for storing digital signatures and timestamps. The globally unique identifier is used to uniquely refer to the electronic evidence throughout the entire process of evidence preservation, auditing, and tracing.

9. The method for storing and tracing electronic evidence based on blockchain according to claim 1, characterized in that, It also includes the step of conducting a compliance audit of the entire process of electronic evidence: A compliance check unit is provided to verify the legality of the digital signature of the electronic evidence, the authenticity of the submitter's identity, and the reasonableness of the evidence's formation time. A compliance check unit is provided to verify the standardization of the timestamp, the legitimacy of the identity of the evidence storage subject, the correctness of the hash calculation process, and the compliance of the blockchain consensus process. Provides a compliance check unit to verify the permissions for evidence retrieval, viewing or export operations based on a role-based access control model, and records the operation records in an append-only manner to a storage area configured to be unmodifiable after a single write. The compliance judgment conclusions generated by the collection compliance check unit, the evidence storage compliance check unit, and the usage compliance check unit are summarized and assembled according to the preset audit report template to generate a digitally signed compliance audit report.

10. A blockchain-based electronic evidence storage and traceability system, used to execute the blockchain-based electronic evidence storage and traceability method according to any one of claims 1 to 9, characterized in that, include: The evidence collection module is configured to receive the original data of electronic evidence to be stored, select the corresponding parsing strategy from a variety of preset differentiated parsing strategies according to the type of electronic evidence, extract information, and generate a unified structured data object with a globally unique identifier. The unified structured data object includes an evidence content field, a metadata field, and a signature field. The hash calculation engine is configured to perform normalized preprocessing on the unified structured data object, and use the preprocessed data as input to calculate the hash value of the preprocessed data as a digital fingerprint. The high-precision timestamp module is configured to obtain high-precision time synchronized with Coordinated Universal Time by receiving signals from the satellite navigation system, generate a timestamp containing the evidence storage time, and have the timestamp containing the evidence storage time digitally signed by the timestamp service organization. The smart contract execution layer is configured to encapsulate the hash value, the timestamp, and the associated metadata into a notarized transaction, and to perform permission verification and authenticity verification on the notarized transaction. The underlying blockchain network adopts a distributed architecture, including multiple consensus nodes, configured to write the verified evidence-stored transactions into the distributed ledger through a consensus mechanism; wherein, multiple evidence-stored records within a single block are organized in a Merkle tree data structure, and adjacent blocks form a chain structure by referencing the hash value of the previous block header.

Images