A data verification method and device based on blockchain

By using smart contracts in the blockchain network for authenticity and relationship verification, the problems of low efficiency and reliability of asset authenticity verification in asset issuance are solved, and efficient and reliable data verification is achieved.

CN113656497BActive Publication Date: 2025-03-28ALIPAY (HANGZHOU) INFORMATION TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202110902233.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2021-08-06
Publication Date
2025-03-28
Estimated Expiration
2041-08-06

AI Technical Summary

Technical Problem

The prior art has low efficiency in verifying asset authenticity in asset issuance and has problems such as data leakage and unreliable verification results.

Method used

The blockchain-based data verification method is adopted to invoke authenticity verification logic and relationship verification logic in the blockchain network through smart contracts to verify the target data and its associated data.

Benefits of technology

It improves the reliability and efficiency of data verification, avoids data leakage and malicious tampering by the middlemen, and enhances the credibility of verification results.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113656497B_ABST
    Figure CN113656497B_ABST
Patent Text Reader

Abstract

The specification discloses a data verification method and device based on blockchain. A data verification method based on blockchain includes: receiving a contract call transaction for data verification initiated by a business system, wherein the contract call transaction carries target data to be verified and associated data corresponding to the target data; in response to the contract call transaction, calling the authenticity verification logic in the smart contract to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain, and obtaining an authenticity verification result; calling the relationship verification logic in the smart contract to verify the logical relationship between the target data and the associated data, and obtaining a logical relationship verification result, and providing the authenticity verification result and the logical relationship verification result as the verification result of the target data to the business system.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a data verification method and device based on blockchain. Background Art

[0002] Data verification scenarios are increasingly common in our daily lives. Taking asset issuance as an example, an important part of asset issuance is to verify the authenticity of the assets. In related technologies, verification can be performed through manual sampling, including a one-by-one comparison of the specific contents of the assets, such as loan contracts or loan details. This method is time-consuming, labor-intensive, and inefficient. Alternatively, asset data can be submitted to a third-party agency for verification, but there are also problems of data leakage and unreliable verification results. Summary of the invention

[0003] In view of this, this specification provides a data verification method and device based on blockchain.

[0004] Specifically, this specification is implemented through the following technical solutions:

[0005] A data verification method based on blockchain is applied to any blockchain node in a blockchain network, wherein a smart contract for data verification is deployed in the blockchain network, and the execution logic corresponding to the contract code of the smart contract includes authenticity verification logic and relationship verification logic, including:

[0006] Receiving a contract call transaction for data verification initiated by a business system, wherein the contract call transaction carries target data to be verified and associated data corresponding to the target data;

[0007] In response to the contract call transaction, the authenticity verification logic in the smart contract is called to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain to obtain an authenticity verification result; the relationship verification logic in the smart contract is called to verify the logical relationship between the target data and the associated data to obtain a logical relationship verification result, and the authenticity verification result and the logical relationship verification result are provided to the business system as the verification result of the target data.

[0008] A blockchain-based verification method, applied to a business system, comprising:

[0009] Receiving a verification request initiated by a user, wherein the verification request carries target data to be verified;

[0010] Searching for associated data corresponding to the target data;

[0011] Generate a contract call transaction for data verification based on the target data and the associated data, wherein the contract call transaction carries the target data and the associated data;

[0012] Sending the contract call transaction to the blockchain node, so that the blockchain node responds to the contract call transaction, calling the authenticity verification logic in the smart contract to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain; calling the relationship verification logic in the smart contract to verify the logical relationship between the target data and the associated data, and obtaining the authenticity verification result and the logical relationship verification result as the verification result of the target data;

[0013] The verification result of the target data is monitored from the blockchain.

[0014] A data verification device based on blockchain, comprising:

[0015] A transaction receiving unit receives a contract call transaction initiated by a business system for data verification, wherein the contract call transaction carries target data to be verified and associated data corresponding to the target data;

[0016] The calling unit, in response to the contract calling transaction, calls the authenticity verification logic in the smart contract to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain, and obtains an authenticity verification result; calls the relationship verification logic in the smart contract to verify the logical relationship between the target data and the associated data, and obtains a logical relationship verification result, and provides the authenticity verification result and the logical relationship verification result as the verification result of the target data to the business system.

[0017] A verification device based on blockchain, comprising:

[0018] A request receiving unit receives a verification request initiated by a user, wherein the verification request carries target data to be verified;

[0019] A search unit, searching for associated data corresponding to the target data;

[0020] A generating unit, which generates a contract call transaction for data verification based on the target data and the associated data, wherein the contract call transaction carries the target data and the associated data;

[0021] A sending unit sends the contract call transaction to a blockchain node, so that the blockchain node responds to the contract call transaction, calls the authenticity verification logic in the smart contract to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain; calls the relationship verification logic in the smart contract to verify the logical relationship between the target data and the associated data, and obtains an authenticity verification result and a logical relationship verification result as the verification result of the target data;

[0022] The monitoring unit monitors the verification result of the target data from the blockchain.

[0023] A data verification device based on blockchain, comprising:

[0024] processor;

[0025] memory for storing machine-executable instructions;

[0026] Wherein, by reading and executing the machine executable instructions corresponding to the blockchain-based data verification logic stored in the memory, the processor is prompted to:

[0027] Receiving a contract call transaction for data verification initiated by a business system, wherein the contract call transaction carries target data to be verified and associated data corresponding to the target data;

[0028] In response to the contract call transaction, the authenticity verification logic in the smart contract is called to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain to obtain an authenticity verification result; the relationship verification logic in the smart contract is called to verify the logical relationship between the target data and the associated data to obtain a logical relationship verification result, and the authenticity verification result and the logical relationship verification result are provided to the business system as the verification result of the target data.

[0029] A data verification device based on blockchain, comprising:

[0030] processor;

[0031] memory for storing machine-executable instructions;

[0032] Wherein, by reading and executing the machine executable instructions corresponding to the blockchain-based data verification logic stored in the memory, the processor is prompted to:

[0033] Receiving a verification request initiated by a user, wherein the verification request carries target data to be verified;

[0034] Searching for associated data corresponding to the target data;

[0035] Generate a contract call transaction for data verification based on the target data and the associated data, wherein the contract call transaction carries the target data and the associated data;

[0036] Sending the contract call transaction to the blockchain node, so that the blockchain node responds to the contract call transaction, calling the authenticity verification logic in the smart contract to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain; calling the relationship verification logic in the smart contract to verify the logical relationship between the target data and the associated data, and obtaining the authenticity verification result and the logical relationship verification result as the verification result of the target data;

[0037] The verification result of the target data is monitored from the blockchain.

[0038] An embodiment of the present specification realizes that the business system can send a contract call transaction for data verification to the blockchain node, and carry the target data and the associated data corresponding to the target data in the transaction. After receiving the contract call transaction, the blockchain node can call the authenticity verification logic in the smart contract to verify the authenticity of the target data based on the hash value of the target data stored on the blockchain. In addition, the relationship verification logic in the smart contract can also be called to verify the logical relationship between the target data and its associated data, and the authenticity verification result and the logical relationship verification result are provided to the business system as the verification result of the target data.

[0039] By adopting the above method, on the one hand, the standard hash value of the target data can be stored in the blockchain in advance, and the data stored on the blockchain is not easy to be tampered with. The authenticity of the target data can be verified based on the standard hash value, thereby improving the reliability of the authenticity verification. On the other hand, the associated data of the target data can also be carried in the transaction and sent to the blockchain node. The blockchain node can also call the smart contract to verify the logical relationship between the target data and the associated data. The data on the blockchain is decentralized, open, transparent and traceable. The verification results obtained based on the smart contract are also credible, which can avoid malicious tampering by the middleman. Compared with the offline verification of the logical relationship, it is more reliable and trustworthy. Moreover, on the basis of the above-mentioned reliable authenticity verification and reliable logical relationship verification, the reliability of data verification will also be greatly improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 It is a schematic diagram of a network environment related to blockchain shown in an exemplary embodiment of this specification;

[0041] Figure 2It is a flowchart of a data verification method based on blockchain shown in an exemplary embodiment of this specification;

[0042] Figure 3 It is a flowchart of a method for storing a standard hash value of asset data as shown in an exemplary embodiment of this specification;

[0043] Figure 4 It is a flowchart of another asset verification method based on blockchain shown in an exemplary embodiment of this specification;

[0044] Figure 5 It is a flowchart of another asset verification method based on blockchain shown in an exemplary embodiment of this specification;

[0045] Figure 6 It is a hardware structure diagram of an electronic device where a blockchain-based asset verification device is located, as shown in an exemplary embodiment of this specification;

[0046] Figure 7 is a block diagram of an asset verification device based on blockchain shown in an exemplary embodiment of this specification;

[0047] Figure 8 It is a block diagram of another blockchain-based asset verification device shown in an exemplary embodiment of this specification. DETAILED DESCRIPTION

[0048] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with this specification. Instead, they are merely examples of devices and methods consistent with some aspects of this specification as detailed in the appended claims.

[0049] The terms used in this specification are for the purpose of describing specific embodiments only and are not intended to limit this specification. The singular forms "a", "the" and "the" used in this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0050] It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0051] With the development of technology, data verification scenarios are becoming more and more common in life. For example, securitization refers to the process of issuing asset-backed securities (ABS) based on the future cash flow generated by the underlying assets, credit enhancement through structured design, and on this basis. At present, in the issuance of securitization (referred to as issuance), an important link is to verify the authenticity of the assets to prevent users from using false ones to defraud funds.

[0052] In the related technology, the assets of the asset holder can be sampled manually, and the authenticity of the randomly sampled assets can be verified, including a one-by-one comparison of the specific contents of the assets such as loan contracts or loan details. This method is time-consuming, labor-intensive, and inefficient. Alternatively, the asset data can be submitted to a third-party agency for verification. During the verification process, the third-party agency can encrypt and decrypt the asset data to improve security, but the reliability of the verification results depends largely on the encryption and decryption algorithms, and there are still problems of data leakage and unreliable verification results.

[0053] Based on this, this specification provides a data verification method and device based on blockchain. Data can be stored on the blockchain, and authenticity verification can be performed based on the data stored on the blockchain. Due to the decentralized and tamper-resistant characteristics of blockchain, the verification method based on blockchain can improve the reliability of data verification.

[0054] Blockchain technology, also known as distributed ledger technology, is an emerging technology in which several computing devices jointly participate in "bookkeeping" and jointly maintain a complete distributed database. Blockchain technology has been widely used in many fields because of its decentralized, open and transparent characteristics, each computing device can participate in database records, and data can be quickly synchronized between computing devices.

[0055] First, the blockchain network environment involved in this specification is described.

[0056] See also Figure 1 , Figure 1It is a schematic diagram of a network environment related to blockchain shown in an exemplary embodiment of this specification.

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

[0058] The client-side computing device 101 may include various types of client-side computing devices, such as PC terminal devices, mobile terminal devices, Internet of Things devices, and other forms of smart devices with certain computing capabilities. The client-side computing device 101 may interact with the blockchain system in a variety of ways.

[0059] In one embodiment, at least some of the computing devices in the client-side computing device 101 can be connected to the server 102 through various communication networks. The server 102 can be a server dedicated to providing a blockchain service interface, such as a BaaS (Blockchain as a Service) platform, also known as a BaaS cloud. The BaaS platform can provide easy-to-use, one-click deployment, fast verification, and flexible and customizable blockchain services for client-side computing devices connected to the BaaS platform by providing pre-written software for activities occurring on the blockchain (such as subscriptions and notifications, user verification, database management, and remote updates), thereby accelerating the development, testing, and launch of blockchain business applications and helping to implement blockchain business application scenarios in various industries.

[0060] See also Figure 1 , Figure 1 The device 3 in the example can be directly connected to the server 102. The device 1 and the device 2 can be first connected to the device 5 (such as a user-side server), and then the device 5 is connected to the server 102.

[0061] Among them, the user-side server can be implemented by a service entity that has built a user account system, and the service entity can include an operating entity that provides various online and / or offline service carriers for users. For example, the service carrier can include various client software that provides online Internet services, such as websites, APPs, mini-programs, etc. For another example, the service carrier can also include various smart devices deployed offline that can provide offline services, such as smart express cabinets deployed in residential areas, office areas, and public places.

[0062] In another embodiment, some computing devices in the client-side terminal device 101 may not be connected to the server 102, but may be directly connected to the blockchain system as blockchain nodes through various communication networks. Figure 1 The device 4 shown in the figure can be directly connected to the blockchain system as a blockchain node.

[0063] The communication network may include a wired and / or wireless communication network, for example, a local area network (LAN), a wide area network (WAN), the Internet or a combination thereof, which is implemented based on a wired access network or a wireless access network (such as a mobile cellular network) provided by an operator.

[0064] The server 102 can be connected to one or more blockchain systems through various communication networks, for example, Figure 1 The server end 102 shown can be connected to blockchain system 103, blockchain system 104 and blockchain system 105 respectively.

[0065] Each blockchain system can maintain one or more blockchains (e.g., public blockchains, private blockchains, consortium blockchains, etc.), and include multiple blockchain nodes for hosting the one or more blockchains; for example, Figure 1 The blockchain nodes 1, 2, 3, 4, and i shown in the figure can jointly carry one or more blockchains. Cross-chain data access can also be performed between the blockchains included in each blockchain system and between each blockchain system.

[0066] In one embodiment, a blockchain node may include a full node and a light node. A full node may download all blockchain transactions contained in each block in the blockchain, and may perform consensus verification on the blockchain transactions contained in each blockchain according to the blockchain consensus algorithm installed. A light node may not download the entire blockchain, but may only download the block header data of each block in the blockchain, and use the data contained in the block header as a verification root to verify the authenticity of the blockchain transaction. A light node may be attached to a full node to access more functions of the blockchain.

[0067] For example, Figure 1 Each blockchain node in the blockchain system 103 shown in FIG. 1 can serve as a full node; and Figure 1 The device 4 directly connected to the blockchain system shown in the figure can be used as a light node and attached to each full node in the blockchain system 103.

[0068] 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 connected to form a network through various types of communication methods (such as TCP / IP) to carry one or more blockchains.

[0069] The following is a description of an embodiment of a data verification method based on blockchain provided in this specification.

[0070] See also Figure 2 , Figure 2 This is a flowchart of a data verification method based on blockchain, shown in an exemplary embodiment of this specification. The method can be applied to any blockchain node in the blockchain network, such as Figure 1 Blockchain node 1 in.

[0071] The method may include the following steps:

[0072] Step 202: receiving a contract call transaction for data verification initiated by the business system, wherein the contract call transaction carries target data to be verified and associated data corresponding to the target data;

[0073] Step 204, in response to the contract call transaction, the authenticity verification logic in the smart contract is called to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain to obtain an authenticity verification result; the relationship verification logic in the smart contract is called to verify the logical relationship between the target data and the associated data to obtain a logical relationship verification result, and the authenticity verification result and the logical relationship verification result are provided to the business system as the verification result of the target data.

[0074] The above steps are described in detail below.

[0075] In this embodiment, the data to be verified may be any type of data, such as asset data, such as loan data, loan data, contract data, and repayment data involved in asset issuance, which may include amount, date, interest rate, etc. Of course, in addition to asset data, other data may also be used, and this embodiment does not impose any special restrictions on the type and content of the data.

[0076] In this embodiment, if the business system wants to verify the authenticity of the data, it can send a contract call transaction for data verification to any blockchain node in the blockchain network, and carry the target data to be verified in the transaction. The transaction can call a smart contract to trigger data verification. In addition, the business system can also find the associated data corresponding to the target data, and carry the associated data in the contract call transaction.

[0077] The associated data is used to verify the logical relationship between it and the target data. For example, the target data is loan data, and the associated data can be contract data, which can verify whether the loan data and the contract data are consistent. The business system can pre-set a mapping relationship between the target data and the associated data to find the associated data based on the mapping relationship.

[0078] After receiving the contract call transaction, the blockchain node can respond to the contract call transaction, call the authenticity verification logic in the smart contract, obtain the standard hash value corresponding to the target data stored on the blockchain, and verify the target data based on the standard hash value. For example, the target hash value of the target data can be calculated, and the target hash value and the standard hash value can be compared to see if they are consistent. If they are consistent, it means that the authenticity verification has passed; if they are inconsistent, it means that the authenticity verification has failed.

[0079] Among them, the standard hash value on the blockchain can be the target data hashed and stored on the blockchain in advance. Based on the characteristics of the blockchain that is not easily tampered with, the standard hash value stored on the blockchain can be considered to be untampered and reliable. It can be used as a storage to verify the target data later, which can improve the reliability of verification. In addition, the hash value of the target data is stored on the blockchain instead of the plain text, which can prevent the plain text data from being leaked and reduce the storage space occupied by the blockchain.

[0080] In this embodiment, the relationship verification logic in the smart contract can also be called to verify the logical relationship between the target data and the associated data. For example, if the target data is loan data and the associated data can be contract data, it can be verified whether the loan amount in the loan data is consistent with the amount specified in the contract. The specific verification method will be described in detail in the following embodiments.

[0081] Among them, this embodiment does not impose any special restrictions on the order of authenticity verification and logical relationship verification, and the two can be performed in parallel; or the authenticity verification can be performed first, and the logical relationship verification can be performed after the authenticity verification passes; of course, the logical relationship verification can also be performed first, and the authenticity verification can be performed after the logical relationship verification passes.

[0082] In this embodiment, the blockchain node can also record the authenticity of the target data and the verification results of the logical relationship as the execution results of the verification transaction in the world state, and the business system can monitor these verification results from the world state. The specific monitoring method can refer to the relevant technology, and this embodiment does not impose any special restrictions on this.

[0083] As can be seen from the above description, in one embodiment of the present specification, the business system can send a contract call transaction for data verification to the blockchain node, and carry the target data and the associated data corresponding to the target data in the transaction. After receiving the contract call transaction, the blockchain node can call the authenticity verification logic in the smart contract to verify the authenticity of the target data based on the hash value of the target data stored on the blockchain. In addition, the relationship verification logic in the smart contract can also be called to verify the logical relationship between the target data and its associated data, and the authenticity verification result and the logical relationship verification result are provided to the business system as the verification result of the target data.

[0084] By adopting the above method, on the one hand, the standard hash value of the target data can be stored in the blockchain in advance, and the data stored on the blockchain is not easy to be tampered with. The authenticity of the target data can be verified based on the standard hash value, thereby improving the reliability of the authenticity verification. On the other hand, the associated data of the target data can also be carried in the transaction and sent to the blockchain node. The blockchain node can also call the smart contract to verify the logical relationship between the target data and the associated data. The data on the blockchain is decentralized, open, transparent and traceable. The verification results obtained based on the smart contract are also credible, which can avoid malicious tampering by the middleman. Compared with the offline verification of the logical relationship, it is more reliable and trustworthy. Moreover, on the basis of the above-mentioned reliable authenticity verification and reliable logical relationship verification, the reliability of data verification will also be greatly improved.

[0085] The following is a description of another embodiment of a blockchain-based data verification method provided in this specification.

[0086] In this embodiment, the target data is used as the verification target asset data as an example for explanation. Of course, in other embodiments, other types of data besides asset data can also be verified, and there is no special limitation on this.

[0087] First, the process of storing the standard hash value of the target asset data in this embodiment is explained.

[0088] See also Figure 3 , Figure 3 This is a flow chart of a method for storing a standard hash value of asset data as shown in an exemplary embodiment of this specification. The method can be applied to any blockchain node in a blockchain network, such as Figure 1Blockchain node 1 in.

[0089] The method may include the following steps:

[0090] Step 302: Receive an asset evidence transaction sent by the business system, wherein the asset evidence transaction carries a standard hash value of the target asset data.

[0091] In this embodiment, the business system may first obtain the target asset data that needs to be stored, and the target asset data may be data held by the business system itself or data provided by other data holders.

[0092] In one example, the target asset data is held by the business system itself. For example, the business system may be an online banking system, which may hold asset data such as the balance of a user account, the user's payment record, and the receipt record. The business system may then obtain the target asset data from the asset data it holds.

[0093] In another example, the business system is a platform for providing asset verification services, but it does not hold the user's asset data. Then the holder of the user's asset data, such as the online bank in the above example, can provide the asset data it holds as the target asset data to the business system. Of course, in order to improve data security, the holder can also encrypt the asset data to avoid leakage during data transmission.

[0094] In this embodiment, the business system can store asset data. The following example takes the storage of a target asset data as an example. For example, the target asset data is loan data, which can include fields such as user, loan amount, loan time, interest rate, etc. For example, see Table 1 below, which exemplifies a target asset data:

[0095] user Loan amount Borrowing time interest rate Borrowing location Loan Methods Zhang San 1000 NTD 2021.1.1 0.1% Beijing loan

[0096] Table 1

[0097] In this embodiment, the standard hash value of the target asset data can be calculated. There are many ways to calculate the standard hash value.

[0098] In one example, a hash calculation may be performed on the target asset data to obtain a standard hash value, wherein the hash algorithm may refer to related technologies, such as MD4, MD5, etc., and no special limitation is imposed on this.

[0099] In another example, a group of asset data including the target asset data may be hashed to obtain a standard hash value, wherein the non-target asset data in the group of data is referred to as auxiliary asset data.

[0100] For example, assuming that the target asset data is a certain contract data, 64 contract data of the same type as the target asset data can be obtained, and the 64 contract data can be hashed to obtain a standard hash value. For example, each of the 64 asset data can be hashed to obtain an initial hash value corresponding to each asset data, and then the 64 initial hash values ​​can be spliced, and the spliced ​​data can be hashed again to obtain a standard hash value. Of course, other methods can also be used to calculate the standard hash value, and this embodiment does not cite examples one by one.

[0101] Using the above method, multiple asset data can be compressed to obtain a standard hash value for evidence storage, which can greatly save storage space on the blockchain.

[0102] In this embodiment, after the business system calculates the standard hash value of the target asset data, it can send an asset evidence transaction to the blockchain node, and the transaction can carry the standard hash value of the target asset data.

[0103] Step 304, in response to the asset notarization transaction, the legitimacy of the asset notarization transaction is verified, and if the verification is passed, consensus is reached with other blockchain nodes in the blockchain network, and the standard hash value is notarized after the consensus is reached.

[0104] In this embodiment, the asset evidence transaction can be implemented by calling a smart contract, or by changing the underlying code of the blockchain so that it can execute native evidence transactions. This embodiment does not impose any special restrictions on this.

[0105] In this embodiment, after receiving the asset evidence transaction, the blockchain node can verify the legitimacy of the transaction.

[0106] The legitimacy verification can be verified, for example, based on various verification mechanisms agreed upon in advance by the blockchain, such as verifying the format of the transaction, the data structure of the transaction, the grammatical structure of the format, the correctness of the digital signature, etc. For details, please refer to the relevant technology, and this embodiment does not impose any special restrictions on this.

[0107] If the legality verification is passed, the asset evidence transaction can be agreed upon with other blockchain nodes in the blockchain network, and the standard hash value of the target asset data can be stored after the consensus is reached. Among them, the consensus method can refer to relevant technologies, such as the consensus algorithm can be the Practical Byzantine Fault Tolerance (PBFT) algorithm, or other algorithms, without special restrictions.

[0108] In this embodiment, after the business system sends an asset notarization transaction to the blockchain node, the blockchain node can return the transaction ID of the transaction. The business system can save the mapping relationship between the transaction ID and the target asset data, and subsequently find the standard hash value corresponding to the notarized target asset data on the blockchain based on the transaction ID.

[0109] Of course, although in this embodiment, the standard hash value is calculated by the business system and then submitted to the blockchain node. In other embodiments, the business system may submit the target asset data to the blockchain node, and the blockchain node may call the smart contract to calculate the standard hash value of the target asset data and store it, and this specification does not impose any special restrictions on this.

[0110] After explaining the above-mentioned method of storing standard hash values, the following describes the method of verifying the target asset data.

[0111] See also Figure 4 , Figure 4 This is a flowchart of another blockchain-based asset verification method shown in an exemplary embodiment of this specification. The method can be applied to any blockchain node in a blockchain network.

[0112] The method may include the following steps:

[0113] Step 402, receiving a contract call transaction initiated by the business system, wherein the contract call transaction carries target asset data and associated asset data to be verified.

[0114] In this embodiment, if the business system wants to verify the authenticity of the target asset data, and also wants to verify the logical relationship between the target asset data and its associated asset data, it can send a contract call transaction for asset verification to the blockchain node, which can carry the target asset data and its associated asset data.

[0115] Similarly, the target asset data and the associated asset data may be data held by the business system itself, or data provided to the business system by other data holders, and there is no special restriction on this.

[0116] Step 404: calculate and obtain the target hash value of the target asset data.

[0117] In this embodiment, after receiving a contract call transaction, the blockchain node can respond to the contract call transaction and first verify the legality of the transaction. The specific verification method refers to the relevant technology and is not particularly limited.

[0118] After the legality verification is passed, the authenticity verification logic in the smart contract can be called to calculate the target hash value of the target asset data. The method for calculating the target hash value is the same as the method for calculating the standard hash value when the target asset data is stored in the aforementioned embodiment.

[0119] In an example, if the standard hash value is obtained by directly performing a hash calculation on the target asset data, the standard hash value can be obtained by performing a hash calculation on the target asset data using the same algorithm.

[0120] In another example, if the standard hash value is calculated from the target asset data and the auxiliary asset data, the business system can also obtain the auxiliary asset data of the target asset data and carry the auxiliary asset data in the contract call transaction. The blockchain node can use the same algorithm to perform hash calculations on the target asset data and the auxiliary asset data to obtain the standard hash value.

[0121] Of course, in other embodiments, the target hash value of the target asset data can also be calculated by the business system, and then the target hash value can be directly carried in the contract call transaction. Then, after the blockchain node receives the contract call transaction, it can directly obtain the target asset data carried in the transaction.

[0122] Step 406, obtain the standard hash value corresponding to the target asset data stored on the blockchain.

[0123] Step 408: Determine whether the target hash value is consistent with the standard hash value.

[0124] In this embodiment, the blockchain node can obtain the standard hash value corresponding to the target asset data stored on the blockchain. For example, the business system can obtain the transaction ID recorded when the target asset data is stored according to the saved mapping relationship, and carry the transaction ID in the contract call transaction. Then, the blockchain node can find the standard hash value of the target asset data stored on the blockchain based on the transaction ID.

[0125] In this embodiment, the blockchain node can determine whether the target hash value and the standard hash value are consistent.

[0126] If they are inconsistent, it means that the authenticity verification result of the target asset data has failed, and step 414 can be executed to obtain the verification result, and the verification result is that the authenticity verification has failed. In addition, if the authenticity verification has failed, the subsequent logical relationship verification will not be performed.

[0127] If they are consistent, it means that the authenticity verification of the target asset data has passed, and step 410 can be executed.

[0128] Of course, for the above-mentioned case where the target asset data and its auxiliary asset data are hashed to obtain the target hash value, since the target hash value is calculated by multiple pieces of data, if the target hash value is inconsistent with the standard hash value, it is not necessarily due to the tampering of the target data, but may also be due to the tampering of the auxiliary data. In this case, the authenticity of the target asset data can also be verified based on the following method:

[0129] For example, when the business system stores the target asset data, it can obtain the target asset data and its corresponding auxiliary asset data, calculate the hash value of the target asset data and the hash value of the auxiliary asset data, and save these hash values. If the target standard hash value and the standard hash value obtained in step 408 are inconsistent, the hash value of the auxiliary asset data can be calculated and compared with the hash value of the stored auxiliary asset data. If they are consistent, it means that the auxiliary asset data has not been tampered with, but the target asset data has been tampered with; if they are inconsistent, it means that the auxiliary data has been tampered with, but the target asset data has not necessarily been tampered with.

[0130] Of course, the above examples are merely illustrative. In actual applications, other methods may also be used for analysis, which are not listed one by one in this embodiment.

[0131] Step 410, obtaining the first designated field of the target asset data and the second designated field of the associated asset data.

[0132] Step 412: verify the logical relationship between the first designated field and the second designated field.

[0133] In this embodiment, in addition to the authenticity verification logic, the smart contract may also include relationship verification logic. When the authenticity verification of the target asset data passes, the relationship verification logic in the smart contract may also be called to verify the logical relationship between the target asset data and the associated asset data.

[0134] The target asset data and the associated asset data may include several fields respectively, and the first designated field of the target asset data and the second designated field of the associated asset data may be obtained, and then the logical relationship between the first designated field and the second designated field may be verified. The first designated field and the second designated field may be all fields of the target asset data and the associated asset data respectively, or may be part of the fields, and there is no special restriction on this.

[0135] In one example, the blockchain may pre-store the mapping relationship between the asset data type and the field to be verified, as well as the standard logical relationship between these fields to be verified. In this example, the first data type of the target asset data and the second data type of the associated asset data may be determined first, and the corresponding field to be verified may be found from the mapping relationship based on the two data types. Then, based on the field to be verified, the first field may be obtained from the target asset data, the second field may be obtained from the associated asset data, and the first specified field and the second specified field may be verified to verify whether they match the standard logical relationship between the fields to be verified.

[0136] For example, assuming that the target asset data is loan data and the associated asset data is repayment data, they may include several fields respectively, as shown in Table 2 and Table 3 below:

[0137]

[0138] Table 2

[0139]

[0140] Table 3

[0141] In addition to carrying the target asset data and associated asset data in the asset verification transaction, the business system can also carry the identifier of its data type. The blockchain receiver can then determine the data type of the target asset data and associated asset data based on the identifier.

[0142] The blockchain can store fields to be verified corresponding to different data types, such as field set 1 to be verified corresponding to the first data type of "loan" and the second data type of "repayment", field set 2 to be verified corresponding to the first data type of "loan" and the second data type of "contract", etc. Corresponding to the above example, the first data type of the target asset data that can be obtained is "loan", and the second data type of the associated asset data is "repayment". The corresponding target relationship verification rules can be found based on these two data types, which is the above field set to be verified.

[0143] The fields to be verified can be determined based on the set of fields to be verified. For example, the set of fields to be verified can include "total loan amount", "remaining unpaid amount", and "interest rate" in the loan data, and "repayment amount" and "interest rate" in the repayment data. Then, the first designated field can be determined from the loan data as "total loan amount", "remaining unpaid amount", and "interest rate", and the second designated field can be determined from the repayment data as "repayment amount" and "interest rate".

[0144] In addition, the standard logical relationship of the field to be verified can also be stored. There can be multiple standard logical relationships, such as the field values ​​of the first specified field and the second specified field match; the field values ​​of the first specified field and the second specified field are calculated according to the specified mathematical method to obtain a result that meets the preset requirements.

[0145] For example, assuming that the standard logical relationship can be that the first specified field "interest rate" matches the second specified field "interest rate". Then the first specified field "interest rate" can be obtained as 0.1%, and the second specified field "interest rate" can be obtained as 0.1%. If the two are found to be consistent, the logical relationship verification is passed.

[0146] For another example, suppose the standard logical relationship is that the difference between the first specified field "total loan amount" and "remaining unpaid amount" is equal to the second specified field "repayment amount". Then the first specified field "total loan amount" can be obtained as 1,000 yuan, and the "remaining unpaid amount" is 300 yuan, and the difference between the two is calculated to be 1,000-300=700 yuan. Then it is matched with the second specified field "repayment amount", and if the two are consistent, the logical relationship verification is passed.

[0147] Of course, the above examples are merely illustrative. In actual applications, other logical relationships can also be verified, such as verifying whether the balance of the loan data is equal to the loan amount of the loan data minus the amount of the repayment data, whether the amount, interest rate, time, and term of the loan data are consistent with the amount, interest rate, time, and term of the contract data, etc. This embodiment does not give examples one by one here.

[0148] It is worth noting that, although the above example uses the verification of the logical relationship between the target data and the associated data as an example, in other embodiments, the logical relationship between the fields of the target data or the associated data itself may also be verified. For example, if the target data includes a repayment date, it may also be verified whether the repayment date exceeds the predetermined period, and this specification does not impose any special restrictions on this.

[0149] In another example, the contract call transaction sent by the business system may also carry the fields to be verified and the standard logical relationship between the fields to be verified specified by the user. The first field may be obtained from the target asset data and the second field may be obtained from the associated asset data according to the fields to be verified, and the first specified field and the second specified field may be verified to see whether they match the standard logical relationship specified by the user.

[0150] In this example, several relationship verification codes may be stored in advance on the blockchain. After receiving the fields to be verified and the standard logical relationship specified by the user, the matching relationship verification code may be found, and the logical relationship between the target asset data and the associated asset data may be verified by executing the code. Among them, the logic corresponding to the relationship verification code may be to verify whether the field values ​​of two fields match, to verify whether the difference between the field values ​​of two fields is equal to the field value of another field, to verify whether the field value of a certain field is greater than or less than a threshold, etc. For specific examples, please refer to the aforementioned embodiments, which will not be described in detail here.

[0151] Furthermore, in this embodiment, before verifying the logical relationship between the target asset data and the associated asset data, the authenticity of the associated asset data may be verified first. The verification method may be the same as the verification method of the target asset data, that is, the hash value corresponding to the associated asset data may be calculated, and the hash value may be compared with the standard hash value stored on the blockchain. If they are consistent, it means that the authenticity of the associated asset data has been verified. For details, please refer to the above embodiment, which will not be repeated here.

[0152] Step 414, obtaining the verification result.

[0153] In this embodiment, the authenticity verification result of the target asset data and the verification result of the logical relationship between it and the associated asset data can be obtained. The blockchain node can record these results into the world state as the verification result of the target asset data.

[0154] As can be seen from the above description, in one embodiment of the present specification, the standard hash value of the target asset data can be stored in the blockchain in advance, and the data stored on the blockchain is not easily tampered with. The authenticity of the target asset data can be verified based on the standard hash value to improve reliability. In addition, the associated asset data of the target asset data can also be carried in the transaction and sent to the blockchain node. The blockchain node can also call the smart contract to verify the logical relationship between the target asset data and the associated asset data. The data on the blockchain is decentralized, open, transparent and traceable. The verification result obtained based on the smart contract is also credible, which can avoid malicious tampering by the middleman. Compared with the offline verification of the logical relationship, it is more reliable and trustworthy. In addition, the logical relationship that needs to be verified can be automatically determined based on the target asset data and the associated asset data, which can simplify the user's operation and improve the user experience.

[0155] The following is a description of another embodiment of a blockchain-based asset verification method provided in this specification.

[0156] See also Figure 5 , Figure 5This is a flowchart of another asset verification method based on blockchain, which is shown in an exemplary embodiment of this specification. The method can be applied to a business system, which can be a system that provides various business services, such as an online banking system, an online shopping platform system, or a system specifically used to provide asset verification services, without any special restrictions.

[0157] The carrier of the business system can be, for example, Figure 1 Device 5 in the example can interact with the user-side devices (device 1, device 2), and can also trade with the server 102 (BaaS platform) to interact with the blockchain node based on the server 102. Of course, the carrier of the business system can also be Figure 1 Device 4 in the figure can directly interact with the blockchain node without any special restrictions.

[0158] The method may include the following steps:

[0159] Step 502: receiving a contract call request initiated by a user, wherein the contract call request carries target asset data to be verified.

[0160] In this embodiment, the user can send an asset verification request to the business system and carry the target asset data to be verified in the request, such as the target asset data itself or the identifier of the target asset data. The business system can obtain the target asset data based on the identifier.

[0161] Step 504, searching for associated asset data corresponding to the target asset data.

[0162] In this embodiment, the business system can find the associated asset data corresponding to the target asset data.

[0163] For example, the associated asset data may be provided by a user, and the user may carry the associated asset data in an asset verification request, and the business system may then obtain the associated asset data based on the request.

[0164] For another example, the business system may store a mapping relationship between target asset data and associated asset data, and then the associated asset data may be found based on the mapping relationship.

[0165] Step 506: Generate a contract call transaction based on the target asset data and the associated asset data, wherein the contract call transaction carries the target asset data and the associated asset data.

[0166] Step 508, sending the contract call transaction to the blockchain node, so that the blockchain node responds to the contract call transaction, calls the authenticity verification logic in the smart contract, and verifies the authenticity of the target asset data based on the standard hash value corresponding to the target asset data stored on the blockchain; if the authenticity verification passes, calls the relationship verification logic in the smart contract to verify the logical relationship between the target asset data and the associated asset data, and obtains the verification result of the target asset data.

[0167] In this embodiment, the business system can generate a contract call transaction based on the target asset data and its associated asset data, and send the transaction to the blockchain node. After receiving the transaction, the blockchain node can verify the authenticity of the target asset data and the logical relationship between it and the associated asset data to obtain the verification result. For details, please refer to the above embodiment, which will not be repeated here.

[0168] Among them, the business system can only carry the target asset data and the associated asset data in the asset verification transaction, and the blockchain node can perform hash calculation on the target asset data to obtain the target hash value, and use the target hash value to compare with the standard hash value stored on the blockchain. Alternatively, the business system can also calculate the target hash value of the target asset data and carry the target hash value in the contract call transaction, so that the blockchain node can directly obtain the target hash value from the transaction. This embodiment does not impose any special restrictions on this.

[0169] Step 510, monitoring the verification result generated by the smart contract from the blockchain.

[0170] In this embodiment, the business system can also monitor the verification results generated by the smart contract from the blockchain, for example, it can monitor the verification results from the world state of the blockchain, and the verification results include the authenticity verification results of the target asset data and the logical relationship verification results.

[0171] The business system can determine whether the authenticity verification result and the logical relationship verification result are both passed; if so, it is determined that the target asset data verification is passed. If the authenticity verification result is not passed, or the authenticity verification result is passed but the logical relationship verification result is not passed, it is determined that the target asset data verification is not passed.

[0172] The business system can send the verification results of the target asset data to the user, and can also send specific authenticity verification results and logical relationship verification results.

[0173] In this embodiment, after the blockchain executes the contract call transaction, it can also return the transaction ID corresponding to the transaction to the business system, and the business system can save the mapping relationship between the transaction ID and the target asset data. If the user wants to know the verification rules of the target asset data, the user can also send an asset query request to the business system, and the verified target asset data can be carried in the request, such as the identifier of the target asset data.

[0174] After the business system receives the asset query request, it can find the transaction ID corresponding to the target asset data according to the above mapping relationship, and based on the transaction ID, find the contract account of the smart contract that verifies the target asset data from the blockchain, and find the relationship verification rules of the target asset data from the contract account. The rules may include fields to be verified, standard logical relationships, and verification results.

[0175] Among them, the contract account should store codes, and the business system can parse these codes to obtain relationship verification rules and send the relationship verification rules to the user. In addition to sending the rules to the user, the logical relationship verification results of each piece of information to be verified specified in the rules can also be sent to the user.

[0176] For example, the content sent to the user can be seen in Table 3 below:

[0177] The logical relationship between the fields to be verified Verify the results Are the loan amount and repayment amount consistent? Consistency Are the loan interest rate and repayment interest rate consistent? Consistency Is the repayment date beyond the deadline? no Is the loan amount greater than 1,000 yuan? yes

[0178] Table 3

[0179] Table 3 above is merely an exemplary result and is not intended to limit the present description.

[0180] Of course, if the relationship verification rules corresponding to the target asset data are provided to the blockchain by the business system, the business system can directly send its own rules to the user, and can also obtain the verification results of the logical relationship of each field to be verified from the blockchain and send them to the user.

[0181] As can be seen from the above description, in one embodiment of the present specification, the business system can receive an asset verification request initiated by a user, obtain the associated asset data of the target asset data based on the request, generate a contract call transaction based on the target asset data and the associated asset data, and send the transaction to the blockchain node so that the blockchain node can verify the authenticity of the target asset data and the logical relationship between the target asset data and its associated asset data. Due to the characteristics of the blockchain that are not easily tampered with, the asset verification process can be ensured to be reliable and trustworthy.

[0182] Furthermore, if the user wants to view the details of the target asset verification process, such as the verification rules and the verification results corresponding to each field to be verified, the user can send a query request to the business system. Based on the request, the business system can find the contract account of the corresponding smart contract from the blockchain, and query the verification rules and verification results from the contract account, and query the verification results from the world state of the blockchain, and provide them to the user. Due to the decentralized, open and transparent characteristics of the blockchain, the verification process is visible to the user, and the verification results are credible and not tampered with, which improves the user experience.

[0183] Corresponding to the aforementioned embodiment of the blockchain-based data verification method, this specification also provides an embodiment of the blockchain-based data verification device.

[0184] The embodiments of the data verification device based on blockchain in this specification can be applied on the server. The device embodiments can be implemented by software, hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by the processor of the electronic device in which it is located reading the corresponding computer program instructions in the non-volatile memory into the memory and running them. From the hardware level, if Figure 6 The following is a hardware structure diagram of the electronic device where the data verification device based on blockchain is located in this manual, except Figure 6 In addition to the processor, memory, network interface, and non-volatile memory shown, the electronic device in which the device in the embodiment is located may also include other hardware according to the actual function of the electronic device, which will not be described in detail.

[0185] Figure 7 It is a block diagram of an asset verification device based on blockchain shown in an exemplary embodiment of this specification.

[0186] Please refer to Figure 7 The asset verification device 700 based on blockchain can be applied in the aforementioned Figure 6 The electronic device shown includes: a transaction receiving unit 710 and a calling unit 720.

[0187] The transaction receiving unit 710 receives a contract call transaction initiated by a business system for data verification, wherein the contract call transaction carries target data to be verified and associated data corresponding to the target data;

[0188] The calling unit 720, in response to the contract calling transaction, calls the authenticity verification logic in the smart contract to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain, and obtains an authenticity verification result; calls the relationship verification logic in the smart contract to verify the logical relationship between the target data and the associated data, and obtains a logical relationship verification result, and provides the authenticity verification result and the logical relationship verification result as the verification result of the target data to the business system.

[0189] Optionally, the verifying the logical relationship between the target data and the associated data includes:

[0190] Acquire a first designated field of the target data and a second designated field of the associated data;

[0191] A logical relationship between the first designated field and the second designated field is verified.

[0192] Optionally, the blockchain pre-stores a mapping relationship between data types and fields to be verified, and stores a standard logical relationship of the fields to be verified;

[0193] The obtaining of the first designated field of the target data and the second designated field of the associated data includes:

[0194] Determine a first data type of the target data and a second data type of the associated data;

[0195] Obtaining from the blockchain a field to be verified that matches the first data type and the second data type;

[0196] Based on the field to be verified, determining a first designated field of the target data and a second designated field of the associated data;

[0197] The verifying the logical relationship between the first designated field and the second designated field includes:

[0198] Verify whether the first specified field and the second specified field match the standard logical relationship corresponding to the field to be verified.

[0199] Optionally, the contract call transaction also carries the fields to be verified specified by the user and the standard logical relationship between the fields to be verified;

[0200] The obtaining of the first designated field of the target data and the second designated field of the associated data includes:

[0201] Based on the field to be verified specified by the user, obtaining the first specified field of the target data and the second specified field of the associated data;

[0202] The verifying the logical relationship between the first designated field and the second designated field includes:

[0203] Verify whether the first designated field and the second designated field match the standard logical relationship.

[0204] Optionally, the logical relationship includes one or more of the following:

[0205] Whether the field values ​​of the first specified field and the second specified field match;

[0206] Whether the results of calculating the field values ​​of the first specified field and the second specified field according to the specified mathematical method meet the preset requirements.

[0207] Optionally, the verifying the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain includes:

[0208] Calculate and obtain a target hash value of the target data;

[0209] Obtain a standard hash value corresponding to the target data from the blockchain;

[0210] Determine whether the target hash value is consistent with the standard hash value;

[0211] If they are consistent, it is determined that the authenticity verification of the target data has passed.

[0212] Figure 8 It is a block diagram of an asset verification device based on blockchain shown in an exemplary embodiment of this specification.

[0213] Please refer to Figure 8 The asset verification device 800 based on blockchain can be applied in the aforementioned Figure 6 The electronic device shown includes: a request receiving unit 810 , a searching unit 820 , a generating unit 830 , a sending unit 840 and a monitoring unit 850 .

[0214] The request receiving unit 810 receives a verification request initiated by a user, wherein the verification request carries target data to be verified;

[0215] A searching unit 820 searches for associated data corresponding to the target data;

[0216] A generating unit 830 generates a contract call transaction for data verification based on the target data and the associated data, wherein the contract call transaction carries the target data and the associated data;

[0217] The sending unit 840 sends the contract call transaction to the blockchain node, so that the blockchain node responds to the contract call transaction, calls the authenticity verification logic in the smart contract to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain; calls the relationship verification logic in the smart contract to verify the logical relationship between the target data and the associated data, and obtains the authenticity verification result and the logical relationship verification result as the verification result of the target data;

[0218] The monitoring unit 850 monitors the verification result of the target data from the blockchain.

[0219] Optionally, the verification result of the target data monitored from the blockchain includes:

[0220] Monitor the authenticity verification results and logical relationship verification results generated by the smart contract used for data verification on the blockchain;

[0221] Determine whether both the authenticity verification result and the logical relationship verification result are passed;

[0222] If so, it is determined that the target data verification has passed.

[0223] Optionally, the monitoring unit 850 further:

[0224] Receiving a query request initiated by a user, wherein the query request carries verified target data;

[0225] Find the contract account of the smart contract for verifying the target data on the blockchain, and find the fields to be verified, the standard logical relationship and the verification result corresponding to the target data from the contract account;

[0226] The fields to be verified, standard logical relationships and verification results are sent to the user.

[0227] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0228] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can refer to the partial description of the method embodiments. The device embodiments described above are only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. Ordinary technicians in this field can understand and implement it without paying creative work.

[0229] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device or a combination of any of these devices.

[0230] Corresponding to the embodiment of the aforementioned blockchain-based data verification method, this specification also provides a blockchain-based data verification device, which includes: a processor and a memory for storing machine-executable instructions. The processor and the memory are usually connected to each other via an internal bus. In other possible implementations, the device may also include an external interface to enable communication with other devices or components.

[0231] In this embodiment, by reading and executing the machine executable instructions corresponding to the blockchain-based data verification logic stored in the memory, the processor is prompted to:

[0232] Receiving a contract call transaction for data verification initiated by a business system, wherein the contract call transaction carries target data to be verified and associated data corresponding to the target data;

[0233] In response to the contract call transaction, the authenticity verification logic in the smart contract is called to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain to obtain an authenticity verification result; the relationship verification logic in the smart contract is called to verify the logical relationship between the target data and the associated data to obtain a logical relationship verification result, and the authenticity verification result and the logical relationship verification result are provided to the business system as the verification result of the target data.

[0234] Optionally, when verifying the logical relationship between the target data and the associated data, the processor is prompted to:

[0235] Acquire a first designated field of the target data and a second designated field of the associated data;

[0236] A logical relationship between the first designated field and the second designated field is verified.

[0237] Optionally, the blockchain pre-stores a mapping relationship between data types and fields to be verified, and stores a standard logical relationship of the fields to be verified;

[0238] When acquiring the first designated field of the target data and the second designated field of the associated data, the processor is prompted to:

[0239] Determine a first data type of the target data and a second data type of the associated data;

[0240] Obtaining from the blockchain a field to be verified that matches the first data type and the second data type;

[0241] Based on the field to be verified, determining a first designated field of the target data and a second designated field of the associated data;

[0242] When verifying the logical relationship between the first designated field and the second designated field, the processor is caused to:

[0243] Verify whether the first specified field and the second specified field match the standard logical relationship corresponding to the field to be verified.

[0244] Optionally, the contract call transaction also carries the fields to be verified specified by the user and the standard logical relationship between the fields to be verified;

[0245] When acquiring the first designated field of the target data and the second designated field of the associated data, the processor is prompted to:

[0246] Based on the field to be verified specified by the user, obtaining the first specified field of the target data and the second specified field of the associated data;

[0247] When verifying the logical relationship between the first designated field and the second designated field, the processor is caused to:

[0248] Verify whether the first designated field and the second designated field match the standard logical relationship.

[0249] Optionally, the logical relationship includes one or more of the following:

[0250] Whether the field values ​​of the first specified field and the second specified field match;

[0251] Whether the results of calculating the field values ​​of the first specified field and the second specified field according to the specified mathematical method meet the preset requirements.

[0252] Optionally, when verifying the authenticity of the target data based on a standard hash value corresponding to the target data stored on the blockchain, the processor is prompted to:

[0253] Calculate and obtain a target hash value of the target data;

[0254] Obtain a standard hash value corresponding to the target data from the blockchain;

[0255] Determine whether the target hash value is consistent with the standard hash value;

[0256] If they are consistent, it is determined that the authenticity verification of the target data has passed.

[0257] Corresponding to the embodiment of the aforementioned blockchain-based data verification method, this specification also provides a blockchain-based data verification device, which includes: a processor and a memory for storing machine-executable instructions. The processor and the memory are usually connected to each other via an internal bus. In other possible implementations, the device may also include an external interface to enable communication with other devices or components.

[0258] In this embodiment, by reading and executing the machine executable instructions corresponding to the blockchain-based data verification logic stored in the memory, the processor is prompted to:

[0259] Receiving a verification request initiated by a user, wherein the verification request carries target data to be verified;

[0260] Searching for associated data corresponding to the target data;

[0261] Generate a contract call transaction for data verification based on the target data and the associated data, wherein the contract call transaction carries the target data and the associated data;

[0262] Sending the contract call transaction to the blockchain node, so that the blockchain node responds to the contract call transaction, calling the authenticity verification logic in the smart contract to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain; calling the relationship verification logic in the smart contract to verify the logical relationship between the target data and the associated data, and obtaining the authenticity verification result and the logical relationship verification result as the verification result of the target data;

[0263] The verification result of the target data is monitored from the blockchain.

[0264] Optionally, when a verification result of the target data is monitored from the blockchain, the processor is prompted to:

[0265] Monitor the authenticity verification results and logical relationship verification results generated by the smart contract used for data verification on the blockchain;

[0266] Determine whether both the authenticity verification result and the logical relationship verification result are passed;

[0267] If so, it is determined that the target data verification has passed.

[0268] Optionally, the processor is further prompted to:

[0269] Receiving a query request initiated by a user, wherein the query request carries verified target data;

[0270] Find the contract account of the smart contract for verifying the target data on the blockchain, and find the fields to be verified, the standard logical relationship and the verification result corresponding to the target data from the contract account;

[0271] The fields to be verified, standard logical relationships and verification results are sent to the user.

[0272] Corresponding to the embodiment of the aforementioned blockchain-based data verification method, this specification also provides a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, the following steps are implemented:

[0273] Receiving a contract call transaction for data verification initiated by a business system, wherein the contract call transaction carries target data to be verified and associated data corresponding to the target data;

[0274] In response to the contract call transaction, the authenticity verification logic in the smart contract is called to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain to obtain an authenticity verification result; the relationship verification logic in the smart contract is called to verify the logical relationship between the target data and the associated data to obtain a logical relationship verification result, and the authenticity verification result and the logical relationship verification result are provided to the business system as the verification result of the target data.

[0275] Optionally, the verifying the logical relationship between the target data and the associated data includes:

[0276] Acquire a first designated field of the target data and a second designated field of the associated data;

[0277] A logical relationship between the first designated field and the second designated field is verified.

[0278] Optionally, the blockchain pre-stores a mapping relationship between data types and fields to be verified, and stores a standard logical relationship of the fields to be verified;

[0279] The obtaining of the first designated field of the target data and the second designated field of the associated data includes:

[0280] Determine a first data type of the target data and a second data type of the associated data;

[0281] Obtaining from the blockchain a field to be verified that matches the first data type and the second data type;

[0282] Based on the field to be verified, determining a first designated field of the target data and a second designated field of the associated data;

[0283] The verifying the logical relationship between the first designated field and the second designated field includes:

[0284] Verify whether the first specified field and the second specified field match the standard logical relationship corresponding to the field to be verified.

[0285] Optionally, the contract call transaction also carries the fields to be verified specified by the user and the standard logical relationship between the fields to be verified;

[0286] The obtaining of the first designated field of the target data and the second designated field of the associated data includes:

[0287] Based on the field to be verified specified by the user, obtaining the first specified field of the target data and the second specified field of the associated data;

[0288] The verifying the logical relationship between the first designated field and the second designated field includes:

[0289] Verify whether the first designated field and the second designated field match the standard logical relationship.

[0290] Optionally, the logical relationship includes one or more of the following:

[0291] Whether the field values ​​of the first specified field and the second specified field match;

[0292] Whether the results of calculating the field values ​​of the first specified field and the second specified field according to the specified mathematical method meet the preset requirements.

[0293] Optionally, the verifying the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain includes:

[0294] Calculate and obtain a target hash value of the target data;

[0295] Obtain a standard hash value corresponding to the target data from the blockchain;

[0296] Determine whether the target hash value is consistent with the standard hash value;

[0297] If they are consistent, it is determined that the authenticity verification of the target data has passed.

[0298] Corresponding to the embodiment of the aforementioned blockchain-based data verification method, this specification also provides a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, the following steps are implemented:

[0299] Receiving a verification request initiated by a user, wherein the verification request carries target data to be verified;

[0300] Searching for associated data corresponding to the target data;

[0301] Generate a contract call transaction for data verification based on the target data and the associated data, wherein the contract call transaction carries the target data and the associated data;

[0302] Sending the contract call transaction to the blockchain node, so that the blockchain node responds to the contract call transaction, calling the authenticity verification logic in the smart contract to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain; calling the relationship verification logic in the smart contract to verify the logical relationship between the target data and the associated data, and obtaining the authenticity verification result and the logical relationship verification result as the verification result of the target data;

[0303] The verification result of the target data is monitored from the blockchain.

[0304] Optionally, the verification result of the target data monitored from the blockchain includes:

[0305] Monitor the authenticity verification results and logical relationship verification results generated by the smart contract used for data verification on the blockchain;

[0306] Determine whether both the authenticity verification result and the logical relationship verification result are passed;

[0307] If so, it is determined that the target data verification has passed.

[0308] Optionally, also include:

[0309] Receiving a query request initiated by a user, wherein the query request carries verified target data;

[0310] Find the contract account of the smart contract for verifying the target data on the blockchain, and find the fields to be verified, the standard logical relationship and the verification result corresponding to the target data from the contract account;

[0311] The fields to be verified, standard logical relationships and verification results are sent to the user.

[0312] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0313] The above description is only a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this specification should be included in the scope of protection of this specification.

Claims

1. A data verification method based on blockchain, applied to any blockchain node in a blockchain network, wherein a smart contract for data verification is deployed in the blockchain network, and the execution logic corresponding to the contract code of the smart contract includes authenticity verification logic and relationship verification logic, and the method includes: Receiving a contract call transaction for data verification initiated by a business system, wherein the contract call transaction carries target data to be verified and associated data corresponding to the target data; In response to the contract call transaction, the authenticity verification logic in the smart contract is called to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain to obtain an authenticity verification result; The relationship verification logic in the smart contract is called to verify the logical relationship between the target data and the associated data to obtain a logical relationship verification result, and the authenticity verification result and the logical relationship verification result are provided to the business system as the verification result of the target data.

2. According to the method of claim 1, the verifying the logical relationship between the target data and the associated data comprises: Acquire a first designated field of the target data and a second designated field of the associated data; A logical relationship between the first designated field and the second designated field is verified.

3. According to the method of claim 2, the blockchain pre-stores the mapping relationship between the data type and the field to be verified, and stores the standard logical relationship of the field to be verified; The obtaining of the first designated field of the target data and the second designated field of the associated data includes: Determine a first data type of the target data and a second data type of the associated data; Obtaining from the blockchain a field to be verified that matches the first data type and the second data type; Based on the field to be verified, determining a first designated field of the target data and a second designated field of the associated data; The verifying the logical relationship between the first designated field and the second designated field includes: Verify whether the first specified field and the second specified field match the standard logical relationship corresponding to the field to be verified.

4. According to the method of claim 2, the contract call transaction also carries the fields to be verified specified by the user and the standard logical relationship between the fields to be verified; The obtaining of the first designated field of the target data and the second designated field of the associated data includes: Based on the field to be verified specified by the user, obtaining the first specified field of the target data and the second specified field of the associated data; The verifying the logical relationship between the first designated field and the second designated field includes: Verify whether the first designated field and the second designated field match the standard logical relationship.

5. According to the method of claim 2, the logical relationship includes one or more of the following: Whether the field values ​​of the first specified field and the second specified field match; Whether the results of calculating the field values ​​of the first specified field and the second specified field according to the specified mathematical method meet the preset requirements.

6. According to the method of claim 1, the authenticity of the target data is verified based on the standard hash value corresponding to the target data stored on the blockchain, including: Calculate and obtain a target hash value of the target data; Obtain a standard hash value corresponding to the target data from the blockchain; Determine whether the target hash value is consistent with the standard hash value; If they are consistent, it is determined that the authenticity verification of the target data has passed.

7. A blockchain-based verification method, applied to a business system, comprising: Receiving a verification request initiated by a user, wherein the verification request carries target data to be verified; Searching for associated data corresponding to the target data; Generate a contract call transaction for data verification based on the target data and the associated data, wherein the contract call transaction carries the target data and the associated data; Sending the contract call transaction to the blockchain node, so that the blockchain node responds to the contract call transaction and calls the authenticity verification logic in the smart contract to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain; Calling the relationship verification logic in the smart contract to verify the logical relationship between the target data and the associated data, and obtaining an authenticity verification result and a logical relationship verification result as a verification result of the target data; The verification result of the target data is monitored from the blockchain.

8. According to the method of claim 7, the verification result of the target data monitored from the blockchain includes: Monitor the authenticity verification results and logical relationship verification results generated by the smart contract used for data verification on the blockchain; Determine whether both the authenticity verification result and the logical relationship verification result are passed; If so, it is determined that the target data verification has passed.

9. The method according to claim 7, further comprising: Receiving a query request initiated by a user, wherein the query request carries verified target data; Find the contract account of the smart contract for verifying the target data on the blockchain, and find the fields to be verified, the standard logical relationship and the verification result corresponding to the target data from the contract account; The fields to be verified, standard logical relationships and verification results are sent to the user.

10. A data verification device based on blockchain, comprising: A transaction receiving unit receives a contract call transaction initiated by a business system for data verification, wherein the contract call transaction carries target data to be verified and associated data corresponding to the target data; The calling unit, in response to the contract calling transaction, calls the authenticity verification logic in the smart contract to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain, and obtains an authenticity verification result; The relationship verification logic in the smart contract is called to verify the logical relationship between the target data and the associated data to obtain a logical relationship verification result, and the authenticity verification result and the logical relationship verification result are provided to the business system as the verification result of the target data.

11. The device according to claim 10, wherein the verifying the logical relationship between the target data and the associated data comprises: Acquire a first designated field of the target data and a second designated field of the associated data; A logical relationship between the first designated field and the second designated field is verified.

12. According to the device of claim 11, the blockchain pre-stores a mapping relationship between data types and fields to be verified, and stores a standard logical relationship of the fields to be verified; The obtaining of the first designated field of the target data and the second designated field of the associated data includes: Determine a first data type of the target data and a second data type of the associated data; Obtaining from the blockchain a field to be verified that matches the first data type and the second data type; Based on the field to be verified, determining a first designated field of the target data and a second designated field of the associated data; The verifying the logical relationship between the first designated field and the second designated field includes: Verify whether the first specified field and the second specified field match the standard logical relationship corresponding to the field to be verified.

13. According to the device of claim 11, the contract call transaction also carries the fields to be verified specified by the user and the standard logical relationship between the fields to be verified; The obtaining of the first designated field of the target data and the second designated field of the associated data includes: Based on the field to be verified specified by the user, obtaining the first specified field of the target data and the second specified field of the associated data; The verifying the logical relationship between the first designated field and the second designated field includes: Verify whether the first designated field and the second designated field match the standard logical relationship.

14. A blockchain-based verification device, comprising: A request receiving unit receives a verification request initiated by a user, wherein the verification request carries target data to be verified; A search unit, searching for associated data corresponding to the target data; A generating unit, which generates a contract call transaction for data verification based on the target data and the associated data, wherein the contract call transaction carries the target data and the associated data; A sending unit sends the contract call transaction to a blockchain node, so that the blockchain node responds to the contract call transaction and calls the authenticity verification logic in the smart contract to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain; Calling the relationship verification logic in the smart contract to verify the logical relationship between the target data and the associated data, and obtaining an authenticity verification result and a logical relationship verification result as a verification result of the target data; The monitoring unit monitors the verification result of the target data from the blockchain.

15. The device according to claim 14, wherein the monitoring unit: Monitor the authenticity verification results and logical relationship verification results generated by the smart contract used for data verification on the blockchain; Determine whether both the authenticity verification result and the logical relationship verification result are passed; If so, it is determined that the target data verification has passed.

16. A data verification device based on blockchain, comprising: processor; memory for storing machine-executable instructions; Wherein, by reading and executing the machine executable instructions corresponding to the blockchain-based data verification logic stored in the memory, the processor is prompted to: Receiving a contract call transaction for data verification initiated by a business system, wherein the contract call transaction carries target data to be verified and associated data corresponding to the target data; In response to the contract call transaction, the authenticity verification logic in the smart contract is called to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain to obtain an authenticity verification result; the relationship verification logic in the smart contract is called to verify the logical relationship between the target data and the associated data to obtain a logical relationship verification result, and the authenticity verification result and the logical relationship verification result are provided to the business system as the verification result of the target data.

17. A data verification device based on blockchain, comprising: processor; memory for storing machine-executable instructions; Wherein, by reading and executing the machine executable instructions corresponding to the blockchain-based data verification logic stored in the memory, the processor is prompted to: Receiving a verification request initiated by a user, wherein the verification request carries target data to be verified; Searching for associated data corresponding to the target data; Generate a contract call transaction for data verification based on the target data and the associated data, wherein the contract call transaction carries the target data and the associated data; Sending the contract call transaction to the blockchain node, so that the blockchain node responds to the contract call transaction, calling the authenticity verification logic in the smart contract to verify the authenticity of the target data based on the standard hash value corresponding to the target data stored on the blockchain; calling the relationship verification logic in the smart contract to verify the logical relationship between the target data and the associated data, and obtaining the authenticity verification result and the logical relationship verification result as the verification result of the target data; The verification result of the target data is monitored from the blockchain.

Citation Information

Patent Citations

  • Block-chain-based data verification method and device, and electronic device

    CN109067541A

  • Logistics service verification method and device based on block chain and electronic equipment

    CN112383607A