A data storage method, apparatus, electronic device, and storage medium

Abstract

This specification provides a data notarization method, apparatus, electronic device, and storage medium. The method includes: obtaining a notarization request for target data submitted by a first user; in response to the notarization request, determining whether the target data is not notarized in a blockchain; if the target data is not notarized in the blockchain, invoking the addition logic contained in a smart contract deployed in the blockchain for data notarization to add an original identifier to the target data to indicate that the target data is a data original held by the first user; in response to adding the original identifier to the target data, further invoking the notarization logic contained in the smart contract to notarize the target data with the added original identifier in the blockchain.

Description

Technical Field

[0001] This specification relates to the field of blockchain technology, and more particularly to a data storage method, apparatus, electronic device, and storage medium. Background Technology

[0002] Electronic data refers to data generated using electronic technology, existing in digital form on media such as disks and magnetic tapes. Its content is separable from the media and can be copied multiple times to other media. Essentially, electronic data is a form of electronic information, enabling precise copying and rapid dissemination in virtual space.

[0003] During the process of electronic data transfer, users often find it difficult to distinguish whether the electronic data they acquire is the original data. Summary of the Invention

[0004] This application provides a data storage method, the method comprising:

[0005] Obtain the evidence storage request submitted by the first user for the target data;

[0006] In response to the evidence storage request, determine whether the target data has been stored in the blockchain;

[0007] If the target data is not stored in the blockchain, the addition logic contained in the smart contract deployed in the blockchain for data storage is invoked to add an original identifier to the target data to indicate that the target data is the original data held by the first user.

[0008] In response to adding the original identifier to the target data, the notarization logic contained in the smart contract is further invoked to notarize the target data with the added original identifier in the blockchain.

[0009] Optionally, before invoking the add logic contained in the smart contract deployed in the blockchain for data notarization, the method further includes:

[0010] The data processing logic contained in the smart contract is invoked to perform standardized data processing on the target data based on a preset data component template, so as to convert the target data into a standardized data component.

[0011] Optionally, before invoking the add logic contained in the smart contract deployed in the blockchain for data notarization, the method further includes:

[0012] The security processing logic contained in the smart contract is invoked to perform security protection processing on the target data.

[0013] Optionally, the security protection process includes any or a combination of the following:

[0014] The target data is re-encoded;

[0015] The target data is then re-obfuscated.

[0016] The data content of the target data is encrypted.

[0017] Optionally, before invoking the add logic contained in the smart contract deployed in the blockchain for data notarization, the method further includes:

[0018] The first user's identity is verified, and in response to the successful verification of the first user's identity, the addition logic contained in the smart contract is further invoked.

[0019] Optionally, before invoking the add logic contained in the smart contract deployed in the blockchain for data notarization, the method further includes:

[0020] Generate a notarization application record for the target data by the first user, and store the generated notarization application record in the distributed ledger of the blockchain.

[0021] Optionally, the adding logic is a signature logic; the original document identifier includes a signature image of a digital seal;

[0022] The step of invoking the smart contract deployed in the blockchain for data notarization, which includes the addition logic, to add an original identifier to the target data to indicate that the target data is the original data document held by the first user, includes:

[0023] The smart contract's signature logic is invoked to obtain the signature image corresponding to the first user's digital seal, and the signature image is added to the target data as an original identifier indicating that the target data is the original data document held by the first user.

[0024] Optionally, the evidence storage request includes the identity information of the first user; obtaining the signature image corresponding to the digital seal of the first user includes:

[0025] Based on the identity information of the first user included in the evidence storage request, obtain the signature image of the first user's digital seal; or,

[0026] Based on the identity information of the first user, a digital seal signature image is generated for the first user.

[0027] Optionally, adding the signature image to the target data as an original document identifier indicating that the target data is the original data document held by the first user includes:

[0028] The stamped image is used as an original document identifier to indicate that the target data is the original data document held by the first user, and is added to the target data in the form of a digital watermark.

[0029] Optionally, the method further includes:

[0030] Generate a notarization record for the target data by the first user, and store the generated notarization application record in the distributed ledger of the blockchain.

[0031] Optionally, the resolution of the digital watermark is greater than the copy resolution.

[0032] Optionally, the method further includes:

[0033] Obtain a verification request submitted by a second user for verifying the legitimacy of target data that has been stored in the blockchain; wherein the verification request includes the identity information of the second user;

[0034] In response to the verification request, the verification logic contained in the smart contract is invoked to extract the original identifier added to the target data from the target data;

[0035] If the original document identifier is not extracted from the target data, then the target data is determined not to be the original data document held by the second user.

[0036] If the original document identifier is extracted from the target data, then based on the identity information of the second user included in the verification request, the identity of the second user is verified, and in response to the failure of the identity verification of the second user, it is determined that the target data is not the original data document held by the second user.

[0037] Optionally, before extracting the original identifier added to the target data from the target data, the method further includes:

[0038] Determine whether the blockchain stores the second user's notarization application record for the target data;

[0039] If not, then it is determined that the stored target data is not the original data document held by the second user;

[0040] If so, then further extract the original identifier added to the target data from the target data.

[0041] Optionally, before extracting the original identifier added to the target data from the target data, the method further includes:

[0042] Determine whether the blockchain stores the evidence storage record of the second user for the target data;

[0043] If not, then it is determined that the stored target data is not the original data document held by the second user;

[0044] If so, then further extract the original identifier added to the target data from the target data.

[0045] This application also provides a data storage device, the device comprising:

[0046] The acquisition unit is used to acquire the evidence storage request for the target data submitted by the first user;

[0047] A determining unit is configured to, in response to the evidence storage request, determine whether the target data has been stored in the blockchain;

[0048] An adding unit is used to, if the target data is not not stored in the blockchain, call the adding logic contained in the smart contract deployed in the blockchain for data storage, and add an original identifier to the target data to indicate that the target data is the original data held by the first user.

[0049] The evidence storage unit is used to, in response to adding the original identifier to the target data, further invoke the evidence storage logic contained in the smart contract to store the target data with the added original identifier in the blockchain.

[0050] This application also provides an electronic device, including a communication interface, a processor, a memory, and a bus, wherein the communication interface, the processor, and the memory are interconnected via the bus;

[0051] The memory stores machine-readable instructions, and the processor executes the above method by invoking the machine-readable instructions.

[0052] This application also provides a machine-readable storage medium storing machine-readable instructions, which, when called and executed by a processor, implement the above-described method.

[0053] In the above embodiments, since a smart contract for data notarization is deployed in the blockchain, in response to a notarization request for target data submitted by the first user, if it is determined that the target data is not notarized in the blockchain, the smart contract's addition logic can be invoked to add an original identifier to the target data, indicating that the target data is the original data held by the first user. Furthermore, the notarization logic contained in the smart contract can be invoked to notarize the target data with the added original identifier in the blockchain. Therefore, even if the original data held by the first user is copied during circulation, the original identifier added to the target data can still be extracted from the copied data, thereby proving that the target data is the original data held by the first user.

[0054] In addition, based on the decentralized, immutable, and traceable characteristics of blockchain, the credibility, traceability, and immutability of the original data held by the user can be guaranteed. Thus, by adding an original identifier to the target data that needs to be stored as evidence for the original data held by the first user, the target data becomes unique, providing technical support for the digitalization of assets. Attached Figure Description

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

[0056] Figure 1 This is a schematic diagram of the application environment of a blockchain-based data storage method in one embodiment of this specification;

[0057] Figure 2 This is a schematic diagram illustrating the creation and invocation of a smart contract in one embodiment of this specification;

[0058] Figure 3 This is a flowchart of a data storage method in one embodiment of this specification;

[0059] Figure 4 This is a schematic diagram of the structure of the electronic device containing the data storage device in one embodiment of this specification;

[0060] Figure 5 This is a block diagram of a data storage device in one embodiment of this specification. Detailed Implementation

[0061] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0062] Electronic data refers to data generated using electronic technology, existing in digital form on media such as disks and magnetic tapes. Its content is separable from the media and can be copied multiple times to other media. Essentially, electronic data is a form of electronic information, enabling precise copying and rapid dissemination in virtual space.

[0063] During the flow of electronic data, users often find it difficult to distinguish whether the electronic data they acquire is the original data, that is, the electronic data initially generated by the creator. For example, electronic data is prone to being intercepted, modified, deleted, or forged, making it difficult for users to determine whether the acquired electronic data is consistent with the original data. Furthermore, electronic data is easily copied, and since the copied data is often completely identical to the copied original data, users find it difficult to determine the copyright ownership of the electronic data.

[0064] Therefore, in application scenarios such as copyright protection of digital works and signing of digital documents, there is currently no effective way to distinguish whether electronic data is the original data held by the creator.

[0065] In view of this, this specification aims to propose a technical solution based on adding an original identifier to the target data to indicate that the target data stored on the chain is a data original held by the user.

[0066] In implementation, a notarization request for target data submitted by a first user can be obtained; in response to the notarization request, it can be determined whether the target data has been notarized in the blockchain; further, if the target data has not been notarized in the blockchain, the addition logic contained in the smart contract deployed in the blockchain for data notarization can be invoked to add an original identifier to the target data to indicate that the target data is the original data held by the first user; in response to adding the original identifier to the target data, the notarization logic contained in the smart contract can be further invoked to notarize the target data with the added original identifier in the blockchain.

[0067] Therefore, in the technical solution described in this specification, because a smart contract for data notarization is deployed in the blockchain, in response to a notarization request for target data submitted by the first user, if it is determined that the target data is not notarized in the blockchain, the smart contract's addition logic can be invoked to add an original identifier to the target data, indicating that the target data is the original data held by the first user. Furthermore, the notarization logic contained in the smart contract can be invoked to notarize the target data with the added original identifier in the blockchain. Therefore, even if the original data held by the first user is copied during circulation, the original identifier added to the target data can still be extracted from the copied data, thus proving that the target data is the original data held by the first user.

[0068] In addition, based on the decentralized, immutable, and traceable characteristics of blockchain, the credibility, traceability, and immutability of the original data held by users can be guaranteed. Thus, based on the original identifier added to the target data to be notified, the target data becomes unique, providing technical support for the digitalization of assets.

[0069] To enable those skilled in the art to better understand the technical solutions in the embodiments of this specification, the relevant blockchain technologies involved in the embodiments of this specification will be briefly described below.

[0070] When using an account-based blockchain to store data, the blockchain node devices need to store and maintain blockchain data, which typically includes block data and account status data corresponding to blockchain accounts. Block data can further include block header data, block transaction data, and transaction receipts corresponding to the block transaction data, etc.

[0071] When storing the various blockchain data shown above, blockchain node devices typically organize this data into a Merkle tree in the database, using key-value pairs. To query this blockchain data stored on the node device, the key of each data point can be used as a query index to traverse the Merkle tree for efficient data retrieval.

[0072] In this type of blockchain model, smart contracts for data notarization can be deployed on the blockchain. Users can call the smart contract to store the data that needs to be notarized as the account status of the contract account corresponding to the smart contract in the Merkle tree corresponding to the smart contract.

[0073] For example, Ethereum typically uses a special Merkle tree called an MPT tree to store and maintain blockchain data. Account state data is organized into an MPT state tree (commonly known as the world state) and stored in the database. The MPT state tree stores key-value pairs with the account address as the key and the account state data as the value. The data stored in the contract account corresponding to a smart contract is further organized into a storage tree (an MPT storage tree used to store data) and stored in the database. The hash value of the root node of the storage tree is used as part of the account state data corresponding to that contract account and populated into the MPT state tree. The hash of the root node of the MPT state tree is then used as the authentication root and further populated into the block header. When a user needs to store data, they can call a smart contract to store the data to be stored as the account state data of the contract account corresponding to that smart contract in the storage tree corresponding to that smart contract.

[0074] In the blockchain field, an important concept is the account. Taking Ethereum as an example, Ethereum typically divides accounts into two categories: external accounts and contract accounts. External accounts are accounts directly controlled by users, also known as user accounts; while contract accounts are accounts created by users through external accounts and contain contract code (i.e., smart contracts). Of course, for some blockchain models derived from the Ethereum architecture (such as Ant Blockchain), the types of accounts supported by the blockchain can be further expanded, which is not specifically limited in this specification.

[0075] For accounts in a blockchain, their state is typically maintained through a structure. When a transaction in a block is executed, the state of the account associated with that transaction in the blockchain usually changes as well.

[0076] In one example, the account structure typically includes fields such as Balance, Nonce, Code, and Storage. Among them:

[0077] The Balance field is used to maintain the current account balance.

[0078] The Nonce field is used to maintain the number of transactions for this account; it is a counter used to ensure that each transaction can be processed exactly once, effectively preventing replay attacks.

[0079] The Code field is used to maintain the contract code of the account; in practice, the Code field usually only maintains the hash value of the contract code; therefore, the Code field is often also called the Codehash field.

[0080] The Storage field is used to maintain the storage content of this account (the default field value is empty). For contract accounts, a separate storage space is usually allocated to store the storage content of the contract account; this separate storage space is usually referred to as the account storage of the contract account.

[0081] The stored content of a contract account is typically constructed into an MPT (Merkle Patricia Trie) tree data structure and stored in the aforementioned independent storage space; the MPT tree constructed based on the stored content of the contract account is also commonly referred to as the Storage tree. The Storage field usually only maintains the root node of this Storage tree; therefore, the Storage field is also commonly referred to as the StorageRoot field.

[0082] For external accounts, the Code and Storage fields shown above are both empty.

[0083] Please see Figure 1 , Figure 1 This is an exemplary embodiment illustrating an application environment diagram of a blockchain-based access verification method.

[0084] In such Figure 1 The network environment shown may include a client-side computing device 101, a server-side device 102, and at least one blockchain system; for example, blockchain system 103, blockchain system 104, and blockchain system 105.

[0085] In one embodiment, the client-side computing device 101 may include various different types of client-side computing devices; for example, client-side computing devices may include PC terminal devices, mobile terminal devices, Internet of Things devices, and other forms of intelligent devices with certain computing capabilities, etc.

[0086] In one implementation, at least a portion of the computing devices in the client-side computing device 101 can be coupled to the server-side 102 via various communication networks; for example... Figure 1 Devices 1 and 2 shown are coupled to server 102.

[0087] It is not difficult to understand that some computing devices in the client-side computing device 101 may not be coupled to the server-side 102, but instead act as blockchain nodes directly coupled to the blockchain system through various communication networks; for example, Figure 1 Device 4 shown in the diagram can be coupled to the blockchain system as a blockchain node.

[0088] The aforementioned communication network may include wired and / or wireless communication networks; for example, it may be a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, based on a wired access network or a wireless access network (such as a mobile cellular network) provided by an operator.

[0089] In one implementation, the client-side computing device 101 may further include one or more user-side servers; for example... Figure 1 Device 5 is shown in the diagram. At least a portion of the computing device in the client-side computing device 101 can be coupled to the user-side server, which can be further coupled to the aforementioned server 102; for example, Figure 1 Devices 1 and 2 shown are coupled to device 5, and device 5 is further coupled to server 102.

[0090] In one implementation, server 102 can also be coupled to one or more blockchain systems via various communication networks; for example... Figure 1 The server 102 shown can be coupled to blockchain system 103, blockchain system 104 and blockchain system 105, etc.

[0091] In one implementation, each blockchain system can maintain one or more blockchains (e.g., public blockchain, private blockchain, consortium blockchain, etc.) and include multiple blockchain nodes for hosting the aforementioned one or more blockchains; for example, such as Figure 1 The blockchain nodes 1, 2, 3, 4, and i shown can collectively support one or more blockchains. Cross-chain data access is also possible between the blockchains within each blockchain system, and between different blockchain systems themselves.

[0092] In one implementation, a blockchain node can be a physical device or a virtual device implemented in a server or server cluster. For example, a blockchain node device can be a physical host in a server cluster, or a virtual machine created by virtualizing the hardware resources of a server or server cluster based on virtualization technology. Each blockchain node can be coupled together to form a network through various types of communication methods (such as TCP / IP) to carry one or more blockchains.

[0093] In one implementation, server 102 may include a BaaS platform (also known as a BaaS cloud) for providing Blockchain as a Service (BaaS). The BaaS platform can provide pre-written software for activities occurring on the blockchain (such as subscriptions and notifications, user authentication, database management, and remote updates) to client-side computing devices coupled to the BaaS platform. This offers easy-to-use, one-click deployment, rapid verification, and flexible customization of blockchain services, thereby accelerating the development, testing, and deployment of blockchain business applications and facilitating the implementation of blockchain commercial application scenarios across various industries.

[0094] In one implementation, the BaaS platform can also provide enterprise-grade platform services based on blockchain technology to help enterprise customers build secure and stable blockchain environments and easily manage the deployment, operation, maintenance and development of blockchains.

[0095] It's important to note that each time a new block is generated in the blockchain, the corresponding states of the executed transactions within that block change accordingly. For example, in a blockchain structured around an account model, the account states of external accounts or smart contract accounts typically change as transactions are executed.

[0096] For example, when a "transfer transaction" in a block is completed, the balances of the sender and receiver accounts associated with that "transfer transaction" (i.e., the values ​​of the Balance field of these accounts) will usually change accordingly.

[0097] For example, the "smart contract call transaction" in the block is used to call the smart contract deployed on the blockchain. The smart contract is called in the EVM corresponding to the node device to execute the "smart contract call transaction", and the account status of the smart contract account is updated in the smart contract account after the execution of the smart contract call transaction.

[0098] In practical applications, public, private, and consortium blockchains can all potentially offer smart contract functionality. A smart contract on a blockchain is a contract that can be triggered and executed through transactions. Smart contracts can be defined in the form of code.

[0099] Taking Ethereum as an example, it allows users to create and invoke complex logic within the Ethereum network. As a programmable blockchain, Ethereum's core is the Ethereum Virtual Machine (EVM), which can be run on every Ethereum node. The EVM is a Turing-complete virtual machine that can implement various complex logics. Users publish and invoke smart contracts on Ethereum, which run on the EVM. In fact, the EVM directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so smart contracts deployed on the blockchain can be bytecode.

[0100] Please see Figure 2 , Figure 2 This is an exemplary embodiment illustrating a schematic diagram of creating and invoking a smart contract.

[0101] Creating a smart contract in Ethereum involves writing the smart contract, converting it into bytecode, and deploying it to the blockchain. Calling a smart contract in Ethereum involves initiating a transaction that points to the smart contract's address. Each node's EVM can execute this transaction, distributing the smart contract code across the virtual machines of every node in the Ethereum network.

[0102] After a user sends a transaction containing information about calling a smart contract to the Ethereum network, each node can execute this transaction in the EVM. The transaction's From field records the address of the account initiating the smart contract call, the To field records the address of the called smart contract, and the Data field records the method and parameters used to call the smart contract. After calling the smart contract, the contract account's state may change. Subsequently, a client can view the contract account's state through the connected blockchain node; for example, the account state can be stored in the smart contract's Storage tree in the form of key-value pairs. The execution result of the smart contract call transaction can be stored in the MPT receipt tree in the form of a transaction receipt.

[0103] Smart contracts can be executed independently on each node of the blockchain in a prescribed manner. All execution records and data are stored on the blockchain. Therefore, once such a transaction is completed, the blockchain stores an immutable and unlost transaction certificate.

[0104] The technical solutions in this specification are described below through specific embodiments and in conjunction with specific application scenarios.

[0105] Please see Figure 3 , Figure 3 This is a flowchart of a data evidence preservation method in one embodiment of this specification. The above data evidence preservation method can be applied to, for example... Figure 1The technical solution described in this specification is implemented in the application environment shown. The data storage method described above can be performed by executing the following steps:

[0106] Step 302: Obtain the evidence storage request for the target data submitted by the first user;

[0107] Step 304: In response to the evidence storage request, determine whether the target data has been stored in the blockchain;

[0108] Step 306: If the target data is not stored in the blockchain, the addition logic contained in the smart contract deployed in the blockchain for data storage is invoked to add an original identifier to the target data to indicate that the target data is the original data held by the first user.

[0109] Step 308: In response to adding the original identifier to the target data, the notarization logic contained in the smart contract is further invoked to notarize the target data with the added original identifier in the blockchain.

[0110] In this specification, the data storage method described can be applied to node devices in a blockchain or to a blockchain service platform.

[0111] For example, the data storage method can be applied to node devices in a blockchain (such as...). Figure 1 In any of the blockchain systems shown, the user's corresponding client-side computing device can be directly connected to the node device.

[0112] For example, the data storage method described above can also be applied to blockchain service platforms (such as...). Figure 1 As shown in the server 102, the user's corresponding client-side computing device can connect to the blockchain service platform and interact with the blockchain system through the blockchain service platform.

[0113] In this specification, a request for evidence storage of the target data submitted by the first user can be obtained.

[0114] The target data can be data provided by the first user that needs to be stored in the blockchain as the original data document held by the first user. The target data can be stored locally on the client-side computing device corresponding to the first user, in the storage space of the blockchain service platform, or in a third-party database; this specification does not impose any limitations on this.

[0115] Specifically, the evidence storage request can be in the form of a smart contract calling a transaction, or it can be in the form of a request message.

[0116] For example, when a first user applies to store the target data as the original data held by the first user, if the client-side computing device corresponding to the first user is directly connected to the node device in the blockchain, the node device can receive the storage request transaction for the target data initiated by the client-side computing device corresponding to the first user. The storage transaction request is used to call the smart contract deployed in the blockchain for data storage.

[0117] For example, if the client-side computing device corresponding to the first user accesses the blockchain through the blockchain service platform, the blockchain service platform can receive a notarization request message for the target data sent by the client-side computing device corresponding to the first user.

[0118] In one embodiment shown, the evidence storage request may include the identity information of the first user. The identity information can be used to identify the corresponding user and can also be used for operations such as authentication of the user; for example, the identity information may specifically include, but is not limited to, a user identifier, the public key corresponding to the user's private key, etc.

[0119] In this specification, in response to receiving a notarization request for the target data submitted by the first user, it can be determined whether the target data has been notarized in the blockchain.

[0120] For example, after receiving a notarization request for the target data submitted by the first user, the node device in the blockchain or the blockchain service platform can locally determine whether the target data has been notarized in the blockchain.

[0121] For example, a smart contract for data notarization is deployed in the blockchain; after receiving the notarization request for the target data submitted by the first user, the node device in the blockchain or the blockchain service platform can call the determination logic contained in the smart contract deployed in the blockchain to determine whether the target data has been notarized in the blockchain.

[0122] For details on the specific implementation methods for determining whether the target data has been stored in the blockchain, please refer to the relevant technologies, which will not be elaborated here.

[0123] In this specification, in response to receiving a notarization request for the target data submitted by the first user, if it is determined that the target data is not notarized in the blockchain, the addition logic contained in the smart contract deployed in the blockchain for data notarization can be invoked to add an original identifier to the target data to indicate that the target data is the original data document held by the first user.

[0124] For example, after receiving a notarization request for the target data submitted by the first user, it can be determined whether the target data has been notarized in the blockchain; if not, the addition logic contained in the smart contract can be called to add an original identifier to the target data, which can be used to indicate that the target data is the original data held by the first user.

[0125] For example, after receiving a notarization request for the target data submitted by the first user, it can be determined whether the target data has been notarized in the blockchain. If it is determined that the target data has been notarized in the blockchain, the target data cannot be notarized as the original data held by the first user. Therefore, the data notarization method can be terminated in advance, and the notarization request for the target data submitted by the first user can be rejected.

[0126] This specification does not restrict the specific implementation of rejecting the first user's request for evidence storage of the target data.

[0127] For example, if a node device or blockchain service platform in the blockchain receives a notarization request message for the target data sent by the first user, it can return a rejection response message corresponding to the notarization request message.

[0128] For example, if a node device or blockchain service platform in the blockchain receives a notarization request transaction for the target data initiated by the first user, it can call the determination logic contained in the smart contract to determine that the target data has been notarized in the blockchain. Then, it can generate a notarized smart contract event for the target data and store the generated smart contract event in the distributed ledger of the blockchain, so that the first user can determine that the notarization request for the target data is rejected when it hears the smart contract event from the distributed ledger.

[0129] In one embodiment, before storing the target data as a data original held by the first user in the blockchain, the target data can be converted into a standardized data original. In implementation, before invoking the addition logic contained in the smart contract deployed in the blockchain for data storage, the method may further include: invoking the data processing logic contained in the smart contract to perform standardized data processing on the target data based on a preset data original template, thereby converting the target data into a standardized data original.

[0130] The data original template can be used to describe the key fields in the target data that need to be notarized; for example, the key fields may include, but are not limited to: the timestamp corresponding to the notarization time of the target data, the identity information of the first user, the original content of the target data, the generation information of the target data, etc. It should be noted that the specific implementation method of the data original template is not limited in this specification, and those skilled in the art can flexibly pre-set the data original template according to their needs.

[0131] For example, after receiving a notarization request for the target data submitted by the first user, it can be determined whether the target data has been notarized in the blockchain; if not, the data processing logic contained in the smart contract can be invoked to perform standardized data processing on the target data based on a preset data original template, so as to convert the target data into a standardized data original; further, the addition logic contained in the smart contract can be invoked to add an original identifier to the target data after standardized data processing.

[0132] In one embodiment, before storing the target data as the original data held by the first user in the blockchain, the target data can be subjected to security protection processing to protect the privacy and security of the original data. In implementation, before invoking the addition logic contained in the smart contract deployed in the blockchain for data storage, the method may further include: invoking the security processing logic contained in the smart contract to perform security protection processing on the target data.

[0133] The security protection processing for the target data may specifically include any or a combination of the following: re-encoding the target data; re-obfuscating the target data; and encrypting the data content of the target data. For specific implementation methods of security protection processing such as data encoding, data obfuscation, and encryption, please refer to relevant technologies, which will not be elaborated here.

[0134] For example, after receiving a notarization request for the target data submitted by the first user, it can be determined whether the target data has been notarized in the blockchain; if not, the security processing logic contained in the smart contract can be invoked to perform security protection processing on the target data; furthermore, the addition logic contained in the smart contract can be invoked to add an original identifier to the target data after security protection processing.

[0135] For example, after receiving a notarization request for the target data submitted by the first user, it can be determined whether the target data has been notarized in the blockchain. If not, the data processing logic contained in the smart contract can be invoked to perform standardized data processing on the target data based on a preset data component template, so as to convert the target data into a standardized data component. Furthermore, the security processing logic contained in the smart contract can be invoked to perform security protection processing on the standardized data after data processing. Furthermore, the addition logic contained in the smart contract can be invoked to add a component identifier to the target data after standardized data processing and security protection processing.

[0136] It should be noted that, in the embodiments shown above, the "re-encoding," data obfuscation, encryption, and other security protection processes can be understood as follows: regardless of whether the first user has already performed security protection processing on the target data before submitting the request for evidence storage of the target data, in order to protect the privacy and security of the original data, the node devices or blockchain service platform in the blockchain will re-perform the security protection processing on the target data.

[0137] Furthermore, it should be noted that in the embodiments shown above, to further protect the privacy and security of the original data, the smart contract can run within the TEE (Trusted Execution Environment) mounted on the node device. That is, the TEE provides a secure space for the execution of data and code, ensuring their confidentiality and integrity. For example, the TEE can maintain rules for encoding / decoding target data, rules for obfuscating / recovering target data, and keys for encrypting / decrypting target data.

[0138] In practical applications, the addition logic included in the smart contract can specifically be signature logic, and the original document identifier can specifically include a signature image of a digital seal.

[0139] In one embodiment shown, the process of invoking the addition logic contained in the smart contract deployed in the blockchain for data notarization, and adding an original identifier to the target data to indicate that the target data is the original data held by the first user, may specifically include: invoking the signature logic contained in the smart contract, obtaining the signature image corresponding to the digital seal of the first user, and adding the signature image as an original identifier to the target data to indicate that the target data is the original data held by the first user.

[0140] For example, after receiving a notarization request for the target data submitted by the first user, it can be determined whether the target data has been notarized in the blockchain; if not, the signature logic contained in the smart contract can be invoked to obtain the signature image corresponding to the digital seal of the first user, and the signature image can be added to the target data as an original document identifier indicating that the target data is the original data document held by the first user.

[0141] In one possible implementation, the blockchain maintains the association between user identity information and digital seals, allowing direct access to the first user's digital seal maintained on the blockchain. Specifically, the process of obtaining the signature image corresponding to the first user's digital seal may include: obtaining the signature image of the first user's digital seal based on the first user's identity information.

[0142] In another possible embodiment, the evidence storage request includes the identity information of the first user, and a digital seal of the first user can be temporarily generated. In implementation, the process of obtaining the signature image corresponding to the digital seal of the first user may specifically include: generating a signature image of the digital seal for the first user based on the first user's identity information.

[0143] In the embodiments shown above, the signing logic contained in the smart contract deployed in the blockchain can be invoked to sign the target data based on the first user's digital seal, so that the signature image corresponding to the first user's digital seal is added to the target data as an original document identifier. Alternatively, the signature image corresponding to the first user's digital seal can also be used as an original document identifier to indicate that the target data is the original data document held by the first user, and added to the target data in the form of a digital watermark.

[0144] In one embodiment shown, the resolution of the digital watermark can be greater than the copy resolution.

[0145] The copying resolution refers to the maximum resolution supported by the copying device. Typically, since the copying resolution is designed with reference to the maximum resolution of the human eye, it usually does not exceed 300 dpi. Regarding the specific value of the digital watermark resolution, those skilled in the art can flexibly set it as needed, and this specification does not impose any special restrictions. For example, if the printing resolution of the printing device is 1200 dpi, then the resolution of the digital watermark can be greater than the copying resolution and less than the printing resolution; that is, the resolution of the digital watermark can take any value within the range of (300 dpi, 1200 dpi).

[0146] It should be noted that, in order to distinguish between the printed and photocopied versions of the target data, the resolution of the digital watermark can be greater than the photocopy resolution. Based on this, when the target data with the digital watermark is printed and then photocopied, the digital watermark will be "lost," making it impossible to detect the digital watermark in the photocopy, thus distinguishing between the printed and photocopied versions.

[0147] For example, the resolution of the digital watermark added to the target data can be 600 dpi, which is greater than the copy resolution of 300 dpi.

[0148] In addition, in one or more embodiments shown above, in order to distinguish between printouts and photocopies based on the digital watermark added to the target data without affecting the preview or printing effect of the target data, the digital watermark may specifically include a blind watermark; that is, the digital image, the signature image, etc. generated for the target data may be added to the target data in the form of a blind watermark.

[0149] Blind watermarking, also known as hidden watermarking, is a digital watermarking method that is invisible to the human eye. It offers strong concealment and can protect the copyright of the carrier file without affecting its appearance. For details on the specific implementation of adding blind watermarks to the target data, please refer to relevant technologies; further details will not be elaborated here.

[0150] In one embodiment, to enhance the credibility of the original data document, in response to receiving a notarization request for the target data submitted by the first user, the notarization request can be approved, thereby ensuring the authenticity of the first user's identity. In implementation, before invoking the addition logic contained in the smart contract deployed in the blockchain for data notarization, the method may further include: verifying the identity of the first user, and in response to the successful identity verification of the first user, further invoking the addition logic contained in the smart contract.

[0151] The specific implementation method for verifying the identity of the first user is not specifically limited in this specification, and those skilled in the art can flexibly set it according to actual needs; for example, if the target data carries a digital signature based on the private key held by the first user, the digital signature of the first user can be verified based on the public key maintained in the blockchain corresponding to the private key held by the first user.

[0152] For example, after receiving a notarization request for the target data submitted by the first user, it can be determined whether the target data has been notarized in the blockchain; if not, the identity of the first user can be verified; in response to the successful identity verification of the first user, the addition logic contained in the smart contract can be further invoked to add an original identifier to the target data to indicate that the target data is the original data held by the first user.

[0153] For example, after receiving a notarization request for the target data submitted by the first user, the identity of the first user can be verified first. In response to the successful verification of the first user's identity, it can be determined whether the target data has been notarized in the blockchain. If it has not been notarized, the addition logic contained in the smart contract can be further invoked to add an original identifier to the target data to indicate that the target data is the original data document held by the first user.

[0154] Furthermore, in the embodiments shown above, if the identity verification for the first user fails, the first user's request for evidence storage of the target data can be rejected.

[0155] In one embodiment, to ensure traceability of the data original's notarization process, in response to receiving a notarization request submitted by the first user for the target data, the notarization request can be recorded, thereby recording that the first user has applied for notarization of the target data. In implementation, before invoking the add logic contained in the smart contract, the method may further include: generating a notarization application record for the target data by the first user, and storing the generated notarization application record in the distributed ledger of the blockchain.

[0156] For example, after receiving a notarization request for the target data submitted by the first user, a notarization application record for the target data by the first user can be generated and the generated notarization application record can be stored in the distributed ledger of the blockchain; and, it can be determined whether the target data has been notarized in the blockchain; if not notarized, the addition logic contained in the smart contract can be called to add an original identifier to the target data to indicate that the target data is the original data held by the first user.

[0157] For example, after receiving a notarization request for the target data submitted by the first user, it can be determined whether the target data has been notarized in the blockchain; if not, a notarization application record for the target data by the first user can be generated and stored in the distributed ledger of the blockchain; and the addition logic contained in the smart contract can be invoked to add an original identifier to the target data to indicate that the target data is the original data held by the first user.

[0158] Therefore, in the various embodiments shown above, the evidence preservation application record can be generated either when the evidence preservation request is approved or when the evidence preservation request is rejected. In other words, the evidence preservation application record can include records corresponding to accepted evidence preservation requests or records corresponding to rejected evidence preservation requests. Those skilled in the art can flexibly set it as needed, and this specification does not impose any limitations. Accordingly, depending on the content of the evidence preservation application record, different verification methods should be used subsequently. For specific implementation methods of verifying the legality of the preserved target data based on the evidence preservation application record, please refer to the description in the relevant sections of this specification, which will not be elaborated here.

[0159] In this specification, in response to adding the original identifier to the target data, the notarization logic contained in the smart contract can be further invoked to notarize the target data with the added original identifier in the blockchain.

[0160] For example, after receiving a notarization request for target data submitted by the first user, in response to the notarization request, if it is determined that the target data is not notarized in the blockchain, the addition logic in the smart contract can be invoked to add an original identifier to the target data to indicate that the target data is the original data held by the first user; furthermore, the notarization logic contained in the smart contract can be invoked to notarize the target data with the added original identifier in the blockchain.

[0161] In one embodiment, to ensure traceability of the data original's notarization process, the data original held by the first user and notarized in the blockchain through the notarization logic contained in the smart contract can be recorded to facilitate subsequent legality verification of the notarized target data. In implementation, the method may further include: generating a notarization record of the first user for the target data, and storing the generated notarization record in the distributed ledger of the blockchain.

[0162] For example, in response to adding an original document identifier to the target data, the notarization logic contained in the smart contract can be invoked to notarize the target data with the original document identifier added in the blockchain. Also, a notarization record of the first user for the target data can be generated, and the generated notarization record and the target data with the digital watermark added can be stored in the distributed ledger of the blockchain.

[0163] In this specification, after responding to the first user's request for evidence preservation of the target data, adding an original identifier to the target data to indicate that the target data is the original data held by the first user, and then preserving the target data with the added original identifier on the blockchain, it can also respond to the second user's request for legality verification of the preservable target data, and determine whether the preservable target data is the original data held by the second user based on the original identifier added to the target data.

[0164] In implementation, the method may further include: obtaining a verification request submitted by a second user for verifying the legality of target data already stored in the blockchain; wherein the verification request includes the identity information of the second user; in response to the verification request, invoking the verification logic contained in the smart contract to extract the original document identifier added to the target data from the target data; if the original document identifier is not extracted from the target data, then determining that the target data is not a data original held by the second user; if the original document identifier is extracted from the target data, then performing identity verification for the second user based on the identity information of the second user included in the verification request, and in response to the failure of the identity verification for the second user, determining that the target data is not a data original held by the second user.

[0165] The first user and the second user may be the same user or different users, and this specification does not impose any restrictions. The terms "first user" and "second user" are used only to distinguish between a user who requests to preserve target data in order to obtain the original data in their possession and a user who requests to verify the legality of the preserved target data.

[0166] The stored target data refers to the data provided by the second user that needs to be verified for legality and corresponds to the original data document held by the second user.

[0167] For example, when a second user needs to verify the legitimacy of target data that has been stored in the blockchain, they can submit a verification request for the stored target data to a node device or blockchain service platform in the blockchain. Further, in response to receiving the verification request submitted by the second user, the node device or blockchain service platform can call the verification logic contained in the smart contract to extract the original document identifier added to the target data. If the original document identifier is not extracted from the target data, it can be determined that the target data is not the original data document held by the second user.

[0168] For example, in response to receiving the verification request submitted by the second user, the node device or blockchain service platform can invoke the verification logic contained in the smart contract to extract the original identifier added to the target data. If the original identifier is extracted from the target data, the identity of the second user can be verified based on the identity information of the second user included in the verification request. If the identity verification of the second user fails, it can be determined that the target data is not the original data held by the second user, but may be illegal data obtained by the second user by copying the original data held by the first user.

[0169] In one embodiment shown, to avoid the original document identifier extracted from the already stored target data being a forged original document identifier, the notarization application records stored in the blockchain can be combined to determine whether the already stored target data is the original data held by the second user, thereby improving the efficiency and accuracy of legality verification.

[0170] In implementation, before extracting the original document identifier added to the target data from the target data, the method may further include: determining whether the blockchain stores a notarization application record of the second user for the target data; if not, determining that the notarized target data is not the original data held by the second user; if so, further extracting the original document identifier added to the target data from the target data.

[0171] For example, in response to receiving a verification request from a second user for the already stored target data, it can be first determined whether the blockchain stores a record of the second user's notarization application for the target data. If the blockchain does not store a record of the second user's notarization application for the target data, it means that the second user has not submitted a notarization request for the target data, and therefore it can be determined that the already stored target data is not the original data held by the second user. If the blockchain stores a record of the second user's notarization application for the target data, it means that the second user has indeed submitted a notarization request for the target data, and therefore the original identifier added to the target data can be further extracted from the already stored target data.

[0172] In another embodiment shown, in order to further improve the efficiency and accuracy of legality verification and avoid the original document identifier extracted from the already stored target data being a forged original document identifier, the stored evidence records stored in the blockchain can also be used to determine whether the already stored target data provided by the second user is an illegal file.

[0173] In implementation, before extracting the original identifier added to the target data from the target data, the method further includes: determining whether the blockchain stores a notarization record of the second user for the target data; if not, determining that the notarized target data is not the original data held by the second user; if so, further extracting the original identifier added to the target data from the target data.

[0174] For example, in response to receiving a verification request from a second user for the already stored target data, it can be first determined whether the blockchain stores a record of the second user's storage of the target data; if the blockchain does not store a record of the second user's storage of the target data, it can be determined that the already stored target data is not the original data held by the second user; if the blockchain stores a record of the second user's storage of the target data, it indicates that the second user did indeed submit a storage request for the target data, and the storage request was accepted, so the original identifier added to the target data can be further extracted from the already stored target data.

[0175] For example, in response to receiving a verification request from a second user for the already stored target data, it can be first determined whether the blockchain stores a record of the second user's notarization application for the target data; if the blockchain stores a record of the second user's notarization application for the target data, it can be further determined whether the blockchain stores a notarization record for the second user's target data; if neither the notarization application record nor the notarization record is stored, it indicates that the second user has not submitted a notarization request for the target data, and it can be determined that the already stored target data is not the original data held by the second user; if the notarization application record is stored but the notarization record is not stored, it indicates that the second user may have submitted a notarization request for the target data, but the notarization request was rejected, and in fact, no original identifier indicating that it is the original data held by the second user was added to the target data, nor was the target data with the original identifier notarized in the blockchain, so it can be determined that the already stored target data is not the original data held by the second user.

[0176] As can be seen from the above embodiments, on the one hand, since a smart contract for data notarization is deployed in the blockchain, in response to a notarization request for target data submitted by the first user, if it is determined that the target data is not notarized in the blockchain, the addition logic contained in the smart contract can be invoked to add an original identifier to the target data, indicating that the target data is the original data held by the first user. Furthermore, the notarization logic contained in the smart contract can be invoked to notarize the target data with the added original identifier in the blockchain. Therefore, even if the original data held by the first user is copied during circulation, the original identifier added to the target data can still be extracted from the copied data, thereby proving that the target data is the original data held by the first user.

[0177] In addition, based on the decentralized, immutable, and traceable characteristics of blockchain, the credibility, traceability, and immutability of the original data held by users can be guaranteed. Thus, based on the original identifier added to the target data to be notified, the target data becomes unique, providing technical support for the digitalization of assets.

[0178] Corresponding to the above-described data evidence storage method embodiments, this specification also provides an embodiment of a data evidence storage device.

[0179] Please see Figure 4 , Figure 4This is a schematic diagram of the electronic device housing the data storage device in one embodiment of this specification. At the hardware level, the device includes a processor 402, an internal bus 404, a network interface 406, memory 408, and non-volatile memory 410, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, for example, the processor 402 reads the corresponding computer program from the non-volatile memory 410 into memory 408 and then runs it. Of course, besides software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution entity of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0180] Please see Figure 5 , Figure 5 This is a block diagram of a data storage device according to one embodiment of this specification. This data storage device can be applied to, for example... Figure 4 The electronic device shown implements the technical solution of this specification. The data storage device may include:

[0181] The acquisition unit 502 is used to acquire the evidence storage request for the target data submitted by the first user;

[0182] The determining unit 504 is used to determine, in response to the evidence storage request, whether the target data has been stored in the blockchain;

[0183] Adding unit 506 is used to call the adding logic contained in the smart contract deployed in the blockchain for data notarization if the target data is not not stored in the blockchain, and add an original identifier for the target data to indicate that the target data is the original data held by the first user.

[0184] The evidence storage unit 508 is used to further call the evidence storage logic contained in the smart contract in response to adding the original identifier to the target data, and to store the target data with the added original identifier in the blockchain.

[0185] In this embodiment, the device further includes:

[0186] A standardized data processing unit is used to call the data processing logic contained in the smart contract, and perform standardized data processing on the target data based on a preset data component template, so as to convert the target data into a standardized data component.

[0187] In this embodiment, the device further includes:

[0188] The security protection processing unit is used to invoke the security processing logic contained in the smart contract to perform security protection processing on the target data.

[0189] In this embodiment, the security protection process includes any or a combination of the following:

[0190] The target data is re-encoded;

[0191] The target data is then re-obfuscated.

[0192] The data content of the target data is encrypted.

[0193] In this embodiment, the device further includes:

[0194] The identity verification unit is used to verify the identity of the first user, and in response to the successful verification of the first user's identity, further invokes the addition logic contained in the smart contract.

[0195] In this embodiment, the device further includes:

[0196] The first generation unit is used to generate a notarization application record of the first user for the target data, and store the generated notarization application record in the distributed ledger of the blockchain.

[0197] In this embodiment, the adding logic is a signature logic; the original document identifier includes a signature image of a digital seal; the adding unit 506 is specifically used for:

[0198] The smart contract's signature logic is invoked to obtain the signature image corresponding to the first user's digital seal, and the signature image is added to the target data as an original identifier indicating that the target data is the original data document held by the first user.

[0199] In this embodiment, the evidence storage request includes the identity information of the first user; the adding unit 506 is specifically used for:

[0200] Based on the identity information of the first user included in the evidence storage request, obtain the signature image of the first user's digital seal; or,

[0201] Based on the identity information of the first user, a digital seal signature image is generated for the first user.

[0202] In this embodiment, the adding unit 506 is specifically used for:

[0203] The stamped image is used as an original document identifier to indicate that the target data is the original data document held by the first user, and is added to the target data in the form of a digital watermark.

[0204] In this embodiment, the device further includes:

[0205] The second generation unit is used to generate a notarization record of the first user for the target data, and to store the generated notarization application record in the distributed ledger of the blockchain.

[0206] In this embodiment, the resolution of the digital watermark is greater than the copy resolution.

[0207] In this embodiment, the device further includes a validity verification unit, used for:

[0208] Obtain a verification request submitted by a second user for verifying the legitimacy of target data that has been stored in the blockchain; wherein the verification request includes the identity information of the second user;

[0209] In response to the verification request, the verification logic contained in the smart contract is invoked to extract the original identifier added to the target data from the target data;

[0210] If the original document identifier is not extracted from the target data, then the target data is determined not to be the original data document held by the second user.

[0211] If the original document identifier is extracted from the target data, then based on the identity information of the second user included in the verification request, the identity of the second user is verified, and in response to the failure of the identity verification of the second user, it is determined that the target data is not the original data document held by the second user.

[0212] In this embodiment, the legality verification unit is further configured to:

[0213] Determine whether the blockchain stores the second user's notarization application record for the target data;

[0214] If not, then it is determined that the stored target data is not the original data document held by the second user;

[0215] If so, then further extract the original identifier added to the target data from the target data.

[0216] In this embodiment, the legality verification unit is further configured to:

[0217] Determine whether the blockchain stores the evidence storage record of the second user for the target data;

[0218] If not, then it is determined that the stored target data is not the original data document held by the second user;

[0219] If so, then further extract the original identifier added to the target data from the target data.

[0220] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0221] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0222] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0223] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0224] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0225] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0226] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0227] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0228] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0229] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0230] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0231] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0232] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0233] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0234] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0235] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0236] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A data evidence storage method, the method comprising: Obtain the evidence storage request submitted by the first user for the target data; In response to the evidence storage request, determine whether the target data has been stored in the blockchain; If the target data is not stored in the blockchain, the signature logic contained in the smart contract deployed in the blockchain for data storage is invoked to obtain the signature image corresponding to the digital seal of the first user, and the signature image is added to the target data as the original document identifier indicating that the target data is the original data document held by the first user. In response to adding the original identifier to the target data, the notarization logic contained in the smart contract is further invoked to notarize the target data with the added original identifier in the blockchain.

2. The method according to claim 1, further comprising, before invoking the signature logic contained in the smart contract deployed in the blockchain for data notarization: The data processing logic contained in the smart contract is invoked to perform standardized data processing on the target data based on a preset data component template, so as to convert the target data into a standardized data component.

3. The method according to claim 2, wherein before invoking the signature logic contained in the smart contract deployed in the blockchain for data notarization, the method further comprises: The security processing logic contained in the smart contract is invoked to perform security protection processing on the target data.

4. The method according to claim 3, wherein the security protection process comprises any or a combination of the following: The target data is re-encoded; The target data is then re-obfuscated. The data content of the target data is encrypted.

5. The method according to claim 1, wherein before invoking the signature logic contained in the smart contract deployed in the blockchain for data notarization, the method further comprises: The identity of the first user is verified, and in response to the successful verification of the first user's identity, the signature logic contained in the smart contract is further invoked.

6. The method according to claim 5, wherein before invoking the signature logic contained in the smart contract deployed in the blockchain for data notarization, the method further comprises: Generate a notarization application record for the target data by the first user, and store the generated notarization application record in the distributed ledger of the blockchain.

7. The method according to claim 1, wherein the evidence storage request includes the identity information of the first user; The step of obtaining the signature image corresponding to the digital seal of the first user includes: Based on the identity information of the first user included in the evidence storage request, obtain the signature image of the first user's digital seal; or, Based on the identity information of the first user, a digital seal signature image is generated for the first user.

8. The method according to claim 1, wherein adding the signature image as an original document identifier indicating that the target data is the original data document held by the first user to the target data comprises: The stamped image is used as an original document identifier to indicate that the target data is the original data document held by the first user, and is added to the target data in the form of a digital watermark.

9. The method according to claim 5, further comprising: Generate a notarized record of the first user for the target data, and store the generated notarized record in the distributed ledger of the blockchain.

10. The method according to claim 8, wherein the resolution of the digital watermark is greater than the copy resolution.

11. The method according to claim 1, further comprising: Obtain a verification request submitted by a second user for verifying the legitimacy of target data that has been stored in the blockchain; wherein the verification request includes the identity information of the second user; In response to the verification request, the verification logic contained in the smart contract is invoked to extract the original identifier added to the target data from the target data; If the original document identifier is not extracted from the target data, then the target data is determined not to be the original data document held by the second user. If the original document identifier is extracted from the target data, then based on the identity information of the second user included in the verification request, the identity of the second user is verified, and in response to the failure of the identity verification of the second user, it is determined that the target data is not the original data document held by the second user.

12. The method of claim 11, further comprising, before extracting the original identifier added to the target data from the target data: Determine whether the blockchain stores the second user's notarization application record for the target data; If not, then it is determined that the stored target data is not the original data document held by the second user; If so, then further extract the original identifier added to the target data from the target data.

13. The method of claim 11, further comprising, before extracting the original identifier added to the target data from the target data: Determine whether the blockchain stores the evidence storage record of the second user for the target data; If not, then it is determined that the stored target data is not the original data document held by the second user; If so, then further extract the original identifier added to the target data from the target data.

14. A data storage device, the device comprising: The acquisition unit is used to acquire the evidence storage request for the target data submitted by the first user; A determining unit is configured to, in response to the evidence storage request, determine whether the target data has been stored in the blockchain; The addition unit is used to, if the target data is not stored in the blockchain, call the signature logic contained in the smart contract deployed in the blockchain for data storage, obtain the signature image corresponding to the digital seal of the first user, and add the signature image to the target data as the original identifier indicating that the target data is the original data held by the first user. The evidence storage unit is used to, in response to adding the original identifier to the target data, further invoke the evidence storage logic contained in the smart contract to store the target data with the added original identifier in the blockchain.

15. An electronic device, comprising a communication interface, a processor, a memory, and a bus, wherein the communication interface, the processor, and the memory are interconnected via the bus; The memory stores machine-readable instructions, and the processor executes the method according to any one of claims 1 to 13 by invoking the machine-readable instructions.

16. A machine-readable storage medium storing machine-readable instructions that, when invoked and executed by a processor, implement the method of any one of claims 1 to 13.

Images