Method, system, storage medium and terminal device for digital file notarization and verification

Abstract

The application relates to the technical field of blockchains, and particularly discloses a digital file storage and verification method and system, a storage medium and a terminal device. The method comprises the following steps: generating a corresponding hash value of a digital asset source file in a local area through a hash algorithm; constructing a UTXO, writing the hash value into the UTXO, and then sending the UTXO to a full node for packaging; collecting information of a block header where the UTXO is located after block output and a Merkle proof; locally storing the information of the block header, the Merkle proof, the digital asset source file and the UTXO; sending the information of the block header, the Merkle proof, the digital asset source file and the UTXO to a verification party; and verifying the digital asset source file by the verification party. The application can store the file without the intervention of a trusted third party, so as to ensure that the stored file cannot be maliciously tampered with, guarantee the effectiveness of the stored file, and be suitable for a blockchain system based on all UTXOs.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchain, in particular to a digital file storage and verification method, system, storage medium and terminal device. BACKGROUND

[0002] In the data era, a large number of data files often contain valuable commercial secrets, creative works, research results, and intellectual property such as works. How to efficiently protect such assets, the industry has proposed a series of storage solutions, for example, WIPO PROOF proposes a fast storage system, which can quickly generate tamper-proof evidence using file hash and timestamp to prove that the digital file exists at a certain time point and has not been modified since it exists. However, WIPO PROOF has many shortcomings, such as: 1. Too expensive, a single transaction fee of 20 Swiss francs, which is a huge expense for a large number of files that need to be stored; 2. Relying on a trusted third party (WIPO organization), since the storage proof is issued by a trusted third party and the verification process is provided by a trusted third party, it increases the risk (for example, the trusted third party is malicious) while increasing the cost; 3. Unable to verify locally, since the digital property storage and verification process requires the participation of a trusted third party, the data property verification party cannot verify the data file storage without accessing the Internet (for example, the WIPO website is down); 4. The cost of data file storage is huge, since data storage has a cost, long-term storage of storage data will incur huge costs, and how to make the digital file owner bear the cost of his own digital file is a problem.

[0003] Therefore, in view of the above problems, the present application aims to provide a new digital file storage and verification scheme. SUMMARY

[0004] In view of the technical problems in the prior art, the present application provides a digital file storage and verification method, system, storage medium and terminal device.

[0005] The digital file storage and verification method of the present application comprises:

[0006] The storage party generates a corresponding hash value for the digital asset source file locally through a hash algorithm;

[0007] UTXO is constructed, the hash value is written into the UTXO, and the UTXO is sent to the full node for packaging;

[0008] The information of the block header where the UTXO is located after the full node is packaged, and the Merkle proof are collected;

[0009] The information of the block header, the Merkle proof, the digital asset source file, and the UTXO are saved locally;

[0010] Send the block header information, Merkel proof, digital asset source file, and UTXO to the verifier;

[0011] The verifier verifies the existence of the digital asset source files.

[0012] Furthermore, the verifier verifies the source files of the digital assets, including:

[0013] The verifier generates a hash value based on the digital asset source file and the hash algorithm, and compares it with the hash value in the UTXO. If they are the same, the digital asset source file has not been tampered with; if they are different, the digital asset source file has been tampered with.

[0014] Furthermore, the verification of the digital asset source files by the verifier also includes:

[0015] The verifier determines whether the UTXO is a child node of the Merkle root in the block header based on the UTXO and the Merkle proof; if so, the existence of the digital asset source file is valid; if not, the existence of the digital asset source file is invalid.

[0016] Furthermore, the verification of the digital asset source files by the verifier also includes:

[0017] The verifier determines the storage time parameters of the digital asset source file based on the generation time of the block header and the block height.

[0018] Furthermore, the evidence storage time parameters include the evidence storage timestamp and the order in which the evidence was stored.

[0019] Furthermore, the hash value is written to the UTXO, including:

[0020] Write the hash value to OP_RETURN, OP_PUSHDATA, or OP_DROP of the UTXO.

[0021] The present invention also includes a system for digital document storage and verification, which adopts the above-described method for digital document storage and verification.

[0022] The present invention also includes a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method for digital file storage and verification as described above.

[0023] The present invention also includes a terminal device comprising a computer-readable storage medium and a processor, wherein,

[0024] A computer-readable storage medium storing computer instructions;

[0025] The processor is configured to run computer instructions to cause the terminal device to perform the digital file storage and verification methods described above.

[0026] The present invention discloses a method, system, storage medium, and terminal device for digital file storage and verification. The storage party uses the hash value of a hash algorithm as the fingerprint of the digital asset source file, enabling verification of the file's authenticity without disclosing the source file. Furthermore, the file can be stored without the intervention of a trusted third party, ensuring that the stored file is not maliciously tampered with and guaranteeing its validity. On the other hand, the hash value generation process is completed locally, greatly ensuring the confidentiality of the digital asset source file. Users do not need to worry about leakage. Local storage only occupies the storage party's storage resources, without occupying the resources of others. Data is only saved when there is a need for storage, greatly reducing the occupation and waste of storage resources. This invention is applicable to blockchain systems based on all UTXO implementations. Attached Figure Description

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

[0028] Figure 1 This is a flowchart illustrating the steps of a method for digital file storage and verification according to an embodiment of the present invention.

[0029] Figure 2 This is a schematic diagram illustrating the implementation principle of a digital file storage and verification method according to an embodiment of the present invention.

[0030] Figure 3 This is a structural diagram of a terminal device according to an embodiment of the present invention; Detailed Implementation

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

[0032] An embodiment of the present invention provides a method for digital file storage and verification, such as... Figure 1 and Figure 2 As shown, it includes the following steps:

[0033] Step S10: The evidence holder generates the corresponding hash value for the digital asset source file locally using a hash algorithm.

[0034] Because hash algorithms have a one-way cryptographic mechanism, the hash value calculated for the source file of a digital asset is unique. The calculated hash value is used as the fingerprint of the source file of the digital asset. The specific content of the source file of the digital asset does not need to be disclosed, so as to protect the trade secrets in the form of the file. However, a hash value can be disclosed in advance to prove that the original content of the file has not been modified.

[0035] In this embodiment, the digital asset source files can be intellectual assets such as innovative creative works, product designs, research results, and books, which need to be stored as trade secrets. Step S20: Construct a UTXO, write the hash value into the UTXO, and then send the UTXO to the full node for packaging.

[0036] Cryptocurrency transactions consist of inputs and outputs. Each transaction requires spending one input and producing one output. The output is the "unspent transaction output," or UTXO. The custodian constructs the UTXO locally and writes the hash value corresponding to the digital asset source file into it. Specifically, this can be written to the UTXO's OP_RETURN, OP_PUSHDATA, or OP_DROP. OP_RETURN functions as a "remark," ending the script with the top value on the stack. This opcode is primarily used to append information as a "remark" to the original opcode, typically for adding information to a transaction. The OP_PUSHDATA opcode pushes the next N bytes of information onto the stack, designated as OP_PUSHDATA1, OP_PUSHDATA2, and OP_PUSHDATA4. This opcode can be used to push information onto the stack or to record information within a transaction. The OP_DROP opcode removes the top element of the stack and is divided into OP_DROP and OP_2DROP. This opcode can push information onto the stack and then delete that information, and can be used to record information in transactions.

[0037] Step S30: Collect the block header information and Merkel proof of the UTXO located by the full node after block production.

[0038] After the notary public sends the UTXO to the full node for packaging, the full node sends the information of the block header containing the UTXO and the Merkel proof (or Merkel path) to the notary public after producing the block.

[0039] A full node, also known as a "transaction processor," stores all user-related transactions, all block headers and Merkel proofs, UTXOs, and other information. It has functions such as producing and forwarding virtual currencies, detecting double-spending, and providing Merkel proofs for transactions.

[0040] A block header is an 80-byte data structure containing a version number, parent block header hash, Merkle root, timestamp, difficulty target, and nonce value. On average, one block is produced every 10 minutes, resulting in approximately 4.2MB of block header data per year. An SPV can quickly verify the legitimacy of received transactions by updating the block header locally, without the need for a full node. An SPV, also known as a "light node" or "user node," stores user-related public and private keys, block headers, Merkle proofs, UTXOs, and other information, possessing some ability to construct and forward transactions.

[0041] Step S40: Localize and save the block header information, Merkel proof, digital asset source file, and UTXO.

[0042] The digital asset source file in this embodiment of the invention can be any type of file, including but not limited to text, video, images, and audio. The storage format can also be arbitrary, as long as it can be hashed. For example, a sentence written on paper can be hashed when it is entered into a TXT document.

[0043] The party storing the evidence will locally preserve the block header information, Merkel proof, digital asset source files, and UTXOs to complete the notarization of the digital asset source files. Clients can locally store the block header information, Merkel proof, digital asset source files, and UTXOs containing hash values ​​without occupying other people's resources. Whoever needs the notarization only stores the data, greatly reducing resource waste.

[0044] This invention provides a method for storing digital asset source files without requiring a trusted third party. The storing party stores the digital asset source files locally, and the hash value generation in step S10 is also completed locally, ensuring the confidentiality of the digital asset source files. Users do not need to worry about the file content being leaked. If verification of the digital asset source files is required, step S50 is executed.

[0045] Step S50: Send the block header information, Merkel proof, digital asset source file, and UTXO to the verifier.

[0046] The storage party sends the block header information, Merkel proof, digital asset source file, and UTXO to the verifier without relying on third-party storage and forwarding.

[0047] Step S60: The verifier verifies the existence of the digital asset source file.

[0048] Anyone can preserve the documents they need without the intervention of a trusted third party, and anyone can locally verify the preserved documents to determine whether the documents have been tampered with and the validity of the preservation time.

[0049] Specifically, in step S60 of this embodiment of the invention, the verification party verifies the existence of the digital asset source file, including:

[0050] The verifier generates a hash value based on the digital asset source file and the hash algorithm, and compares it with the hash value in the UTXO. If they are the same, the digital asset source file has not been tampered with; if they are different, the digital asset source file has been tampered with.

[0051] Specifically, in step S60 of this embodiment of the invention, the verification of the existence of the digital asset source file by the verification party further includes:

[0052] The verifier determines whether the UTXO is a child node of the Merkle root in the block header based on the UTXO and the Merkle proof; if so, the existence of the digital asset source file is valid; if not, the existence of the digital asset source file is invalid.

[0053] Specifically, in step S60 of this embodiment of the invention, the verification of the existence of the digital asset source file by the verification party further includes:

[0054] The verifier determines the storage time parameters of the digital asset source file based on the generation time of the block header and the block height.

[0055] The evidence storage time parameters in this embodiment include evidence storage timestamp, evidence storage order, etc.

[0056] Since public blockchains based on proof-of-work have built-in timestamp functionality, and by judging information such as block height and timestamp in the block header, the time parameters when the file was saved can be determined. Because this timestamp can be independently verified by entities in different countries without relying on trust in a trusted timestamp service provider, it can be effectively verified.

[0057] This invention discloses a system for digital document storage and verification. The system includes a storage party, a client corresponding to the verification party, and a blockchain structure, and implements corresponding methods for digital document storage and verification, such as... Figure 1 As shown, the specific methods include:

[0058] Step S10: The evidence holder generates the corresponding hash value for the digital asset source file locally using a hash algorithm.

[0059] Step S20: Construct a UTXO, write the hash value into the UTXO, and then send the UTXO to the full node for packaging.

[0060] Step S30: Collect the block header information and Merkel proof of the UTXO located by the full node after block production.

[0061] Step S40: Localize and save the block header information, Merkel proof, digital asset source file, and UTXO.

[0062] Step S50: Send the block header information, Merkel proof, digital asset source file, and UTXO to the verifier.

[0063] Step S60: The verifier verifies the existence of the digital asset source file.

[0064] In step S60, the verification of the existence of the digital asset source file by the verifier also specifically includes:

[0065] The verifier generates a hash value based on the digital asset source file and the hash algorithm, and compares it with the hash value in the UTXO. If they are the same, the digital asset source file has not been tampered with; if they are different, the digital asset source file has been tampered with.

[0066] Furthermore, the verifier determines, based on the UTXO and the Merkle proof, whether the UTXO is a child node of the Merkle root in the block header; if so, the existence of the digital asset source file is legitimate; if not, the existence of the digital asset source file is illegitimate.

[0067] Furthermore, the verifier determines the notarization time parameters of the digital asset source file based on the block header generation time and block height. These notarization time parameters include the notarization timestamp and the order of notarization.

[0068] The present invention also protects a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described method for digital file storage and verification.

[0069] This invention also protects a terminal device 10, such as... Figure 3 As shown, it includes a computer-readable storage medium 101 and a processor 102, wherein the computer-readable storage medium 101 stores computer instructions; the processor 102 is configured to execute the computer instructions to cause the terminal device 10 to perform the above-described method for digital file storage and verification.

[0070] Through the above description of the embodiments, those skilled in the art can clearly understand that the present invention can be implemented by means of software combined with a hardware platform. Based on this understanding, all or part of the technical solution of the present invention that contributes to the background art can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, smartphone, or network device, etc.) to execute the methods of various embodiments or some parts of the embodiments of the present invention.

[0071] The present invention discloses a method, system, storage medium, and terminal device for digital file notarization and verification. The notarization party uses the hash value of a hash algorithm as the fingerprint of the digital asset source file, enabling verification of the file's authenticity without disclosing the source file. Furthermore, notarization can be performed without the intervention of a trusted third party, ensuring the notarized file is not maliciously tampered with and guaranteeing its validity. On the other hand, the notarization party generates the hash value locally, which greatly ensures the confidentiality of the digital asset source file. Users do not need to worry about leakage. Local notarization only occupies the notarization party's storage resources and does not require the resources of others. Data is only saved when there is a notarization need, greatly reducing the occupation and waste of storage resources. This invention is applicable to blockchain systems based on all UTXO implementations.

[0072] The present invention has been further described above with reference to specific embodiments. However, it should be understood that the specific description herein should not be construed as limiting the nature and scope of the present invention. Various modifications made to the above embodiments by those skilled in the art after reading this specification are all within the scope of protection of the present invention.

Claims

1. A method for digital file notarization and verification, characterized in that, The system comprises: a storage party generates a corresponding hash value for a digital asset source file locally through a hash algorithm; a UTXO is constructed, the hash value is written into the UTXO, and the UTXO is sent to a full node for packaging; information of a block header in which the UTXO is located after block generation and a Merkle proof are collected from the full node; the information of the block header, the Merkle proof, the digital asset source file, and the UTXO are locally saved; the information of the block header, the Merkle proof, the digital asset source file, and the UTXO are sent to a verification party; the verification party verifies the existence of the digital asset source file; the verification party verifies the existence of the digital asset source file, comprising: the verification party generates a hash value according to the digital asset source file and a hash algorithm, and compares the hash value with the hash value in the UTXO, if the hash values are the same, the digital asset source file is not tampered with, if the hash values are different, the digital asset source file is tampered with; the verification party verifies the existence of the digital asset source file, further comprising: the verification party determines whether the UTXO is a child node of the Merkle root in the block header according to the UTXO and the Merkle proof, if yes, the existence of the digital asset source file is legal, if no, the existence of the digital asset source file is illegal.

2. The method for digital file notarization and verification of claim 1, wherein, the verification party verifies the existence of the digital asset source file, further comprising: the verification party determines a storage time parameter of the digital asset source file according to the generation time of the block header and the block height.

3. The method for digital file notarization and verification of claim 2, wherein, the storage time parameter comprises a storage time stamp and a storage sequence.

4. The method of claim 1, wherein, writing the hash value into the UTXO comprises: writing the hash value into OP_RETURN, or OP_PUSHDATA, or OP_DROP of the UTXO.

5. A system for digital file notarization and verification, characterized in that, The system adopts the method for storing and verifying a digital file according to any one of claims 1-4.

6. A computer-readable storage medium, characterized in that, The computer program is stored on the computer readable storage medium, and the computer program is executed by the processor to realize the method for storing and verifying a digital file according to any one of claims 1-4.

7. A terminal device, characterized by comprising: The system comprises a computer readable storage medium and a processor, wherein the computer readable storage medium stores computer instructions; the processor is configured to run the computer instructions to enable the terminal device to execute the method for storing and verifying a digital file according to any one of claims 1-4.

Images