A method and device for constructing a data verification system

Abstract

This specification discloses a method and device for constructing a data verification system, which is applied to an evidence storage service platform. The evidence storage service platform is configured with a general template for defining fields and a set of general verification components, each verification component having the ability to verify the field value of at least one data type; the evidence storage service platform is connected to at least one data evidence storage demander; the method includes: providing a verification requirement configuration interface to the target evidence storage demander; creating a custom data structure for the target evidence storage demander's data to be stored based on the operation of the target evidence storage demander based on the configuration interface, and determining the fields with verification requirements and the corresponding verification components in the custom data structure; constructing a data verification system based on the created custom data structure, the fields with verification requirements and the corresponding verification components, and returning the call identifier for calling the data verification system to the target evidence storage demander.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of computer application technology, and more particularly, to a method and device for constructing a data verification system. Background Art

[0002] Currently, there is usually a need for business data storage for different business scenarios. For example, in the logistics business scenario, in order to ensure the safe transportation of goods, freight companies can upload the logistics records of freight vehicles to the blockchain for storage, so as to determine whether there are any problems during the transportation of goods; for example, in the stock trading business scenario, in order to ensure the security of transaction data, the stock trading platform can upload the transaction data to the blockchain for storage in real time after the transaction is completed, so as to facilitate the audit of the transaction data.

[0003] Before business data is stored, it must first be verified. However, the existing method of developing customized verification systems for different business scenarios is cumbersome and has high development costs. Summary of the Invention

[0004] To solve the above technical problems, this specification discloses a method and device for constructing a data verification system. The technical solution is as follows.

[0005] A method for constructing a data verification system, applied to a proof storage service platform, wherein the proof storage service platform is configured with a universal template for defining fields and a set of universal verification components, each of which is capable of verifying the authenticity of field values of at least one data type. The proof storage service platform is connected to at least one data proof storage requester, each of which has a data proof storage requester requirement. The method is used to construct a verification system for the target proof storage requester's data to be stored.

[0006] The method comprises:

[0007] Providing a verification requirement configuration interface to the target evidence storage requester, wherein the configuration interface is used to: enable the target evidence storage requester to define one or more fields based on the general template, and, for at least one defined field, select a verification component from the general verification component set for verifying the field;

[0008] Creating a custom data structure for the target evidence storage requester's data to be stored based on the configuration interface according to the target evidence storage requester's operation, and determining the fields with verification requirements and corresponding verification components in the custom data structure;

[0009] Based on the created custom data structure, the fields with verification requirements, and the corresponding verification components, a verification smart contract is generated as a data verification system, and the verification smart contract is deployed to the blockchain network; wherein, the verification smart contract is used to verify the data to be stored that has been stored in the blockchain network.

[0010] A data verification system construction device is applied to a proof storage service platform. The proof storage service platform is configured with a universal template for defining fields and a universal verification component set, each verification component capable of verifying field values of at least one data type. The proof storage service platform is connected to at least one data proof storage requester who has a data verification requirement. The device is used to construct a verification system for the target proof storage requester's data to be stored.

[0011] The device comprises:

[0012] An interface providing unit is configured to provide a verification requirement configuration interface to the target evidence storage requester, wherein the configuration interface is configured to enable the target evidence storage requester to define one or more fields based on the general template, and to select, for at least one defined field, a verification component from the general verification component set for verifying the field;

[0013] A verification requirement definition unit is configured to create a custom data structure for the target evidence storage requester's data to be stored based on the operation of the target evidence storage requester based on the configuration interface, and to determine the fields with verification requirements and corresponding verification components in the custom data structure;

[0014] Verification system construction unit: used to generate a verification smart contract as a data verification system based on the created custom data structure, fields with verification requirements and corresponding verification components, and deploy the verification smart contract to the blockchain network; wherein, the verification smart contract is used to verify the data to be stored that has been stored in the blockchain network.

[0015] In the above technical solution, the evidence storage requester can leverage the pre-deployed universal templates and universal verification component set on the evidence storage service platform to customize the data structure for the data to be stored. They can also select the verification component used to verify at least one field in the data structure, thereby specifying the business scenario-specific configurations required to build the verification system. The evidence storage service platform can then build a dedicated data verification system for the evidence storage requester based on the business scenario-specific configurations specified by the evidence storage requester.

[0016] The Evidence Storage Service Platform has pre-deployed a set of common templates and verification components as the foundational technical infrastructure for building verification systems. Evidence requesters only need to specify the relevant business scenario configurations based on this infrastructure, and the Evidence Storage Service Platform will then build a dedicated verification system for them. This avoids duplication of effort among different parties developing their own verification systems, reduces the development workload, and saves development costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of this specification. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0018] Figure 1 This is a flow chart of a method for constructing a data verification system provided in an embodiment of this specification;

[0019] Figure 2 This is a schematic diagram of the principle of a data verification system construction method provided in an embodiment of this specification;

[0020] Figure 3 This is a flow chart of a data verification method provided in an embodiment of this specification;

[0021] Figure 4 This is a structural diagram of a data verification system construction device provided in an embodiment of this specification;

[0022] Figure 5 This is a structural diagram of a data verification device provided in an embodiment of this specification;

[0023] Figure 6 It is a structural diagram of a device used to configure the method of the embodiment of this specification. DETAILED DESCRIPTION

[0024] In order to enable those skilled in the art to better understand the technical solutions in the embodiments of this specification, the technical solutions in the embodiments of this specification will be described in detail below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art should fall within the scope of the disclosure.

[0025] Currently, there is usually a need for business data storage for different business scenarios. For example, in the logistics business scenario, in order to ensure the safe transportation of goods, freight companies can upload the logistics records of freight vehicles to the blockchain for storage, so as to determine whether there are any problems during the transportation of goods; for example, in the stock trading business scenario, in order to ensure the security of transaction data, the stock trading platform can upload the transaction data to the blockchain for storage in real time after the transaction is completed, so as to facilitate the audit of the transaction data.

[0026] In practical applications, it is often necessary to verify the business data being stored. Verification can specifically refer to verifying the authenticity of one or more pieces of information related to the actual situation contained in the business data, or it can also refer to verifying the format of some data contained in the business data.

[0027] To facilitate understanding, two examples of authenticity verification are given below.

[0028] Example 1: In a logistics business scenario, business data might include logistics records uploaded by freight vehicles upon arrival at a freight transfer station. These records might include the vehicle number, driver's name, cargo type, cargo quantity, and the time the vehicle arrived at the transfer station. The authenticity of these time and cargo quantities is crucial to the business. Therefore, verification of these logistics records might specifically include verifying the authenticity of these time and cargo quantities.

[0029] Specifically, the entry and exit records of freight vehicle A can be searched from the vehicle entry and exit records stored in the freight transfer station system. The time information of freight vehicle A's arrival at the freight transfer station can be extracted from the entry and exit records of freight vehicle A. The time information extracted from the entry and exit records can then be compared and verified with the time information in the logistics records uploaded by freight vehicle A to determine whether the time information is authentic.

[0030] The cargo verification record of freight vehicle A can also be searched from the vehicle cargo verification records stored in the freight transfer station system, and the cargo quantity on freight vehicle A can be extracted from the cargo verification record of freight vehicle A. The cargo quantity extracted from the verification record can then be compared with the cargo quantity in the logistics record uploaded by freight vehicle A to determine whether the cargo quantity is authentic.

[0031] Example 2: In a medical insurance business scenario, business data might be a medical policy uploaded by an insurer for use in claiming medical insurance compensation. This data might include information such as the insurer, total medical expenses, and the claimed compensation amount. The insurer's total medical expenses can be used to determine the medical insurance compensation amount, and the authenticity of this total expense information is crucial for the business. For example, an insurer could falsify total expense information to increase the compensation amount. Therefore, verification of medical insurance policies might specifically involve verifying the authenticity of the total expense information.

[0032] Specifically, the system can obtain detailed medical bills for Insured Person B from the hospital where Insured Person B was treated, and then obtain the actual total expenditure information for Insured Person B from the medical bill details. The total expenditure information obtained from the medical bill details can then be compared and verified with the total expenditure information uploaded by Insured Person B to determine whether the total expenditure information is authentic.

[0033] For different business scenarios, data storage and evidence demanders in different business scenarios usually independently develop and develop customized data verification systems for their respective business scenarios. The developed data verification systems have the ability to verify the information contained in the business data.

[0034] For example, by developing a data verification system, the system can be used to obtain real information and compare and verify it with the information contained in the business data; it can also be used to verify the format of some data contained in the business data.

[0035] However, there are the following technical problems when different parties requiring evidence independently develop verification systems.

[0036] First of all, each party that needs evidence storage needs to independently carry out the full process development of the verification system, which has a high technical threshold, is time-consuming and labor-intensive, and has high development costs.

[0037] Secondly, the types of data that need to be verified may overlap in different business scenarios. For example, both ride-hailing and food delivery scenarios require location information. Therefore, when different data storage providers independently develop data verification systems, they will develop capabilities specifically for verifying location information. Overall, this is a duplication of verification capabilities that should only be developed once, wasting development resources.

[0038] To solve the above technical problems, this specification provides a method for building a data verification system. Specifically, for multiple data evidence demanders, a data evidence service platform can be set up to build a customized verification system for each data evidence demander.

[0039] The evidence storage service platform can be pre-deployed with a set of universal verification components. One of these universal verification components provides at least one verification capability. Evidence requesters can select a set of verification components and specify the verification object for each selected verification component, thereby obtaining a dedicated verification system. This eliminates the need for each evidence requester to independently develop a full verification system. Instead, they can select the set of verification components they need from the universal verification components provided by the evidence storage service platform, thus saving significant development effort and improving development efficiency. Furthermore, the universal verification components provided by the evidence storage service platform can be reused by different evidence requesters, avoiding the waste of resources caused by duplicate development.

[0040] In practice, each evidence requester's dedicated verification system can be deployed on the evidence service platform. Each evidence requester submits the data to be stored to the evidence service platform for verification and storage. The evidence service platform needs to connect with different evidence requesters and verify their data based on a common set of verification components.

[0041] It should be noted that, considering that the evidence service platform needs to be able to extract the objects that need to be verified from the data to be stored of any evidence demander, and call the corresponding general verification components to verify the extracted objects, the evidence demander is usually required to register the data structure of its own data to be stored with the evidence service platform in advance, so that the evidence service platform can clearly understand the data structure of the data to be stored of the evidence demander, and clearly understand which fields in the data structure are the objects that need to be verified.

[0042] Based on this, in one or more embodiments of the present specification, the evidence service platform also needs to deploy a general template for defining fields. Before building a verification system for any evidence demander, the evidence service platform will provide the general template to the evidence demander to define the fields, thereby clarifying the data structure of the data to be stored by the evidence demander. In addition, the evidence service platform also needs to clarify which fields in the data structure are objects that need to be verified, and which verification component should be called to verify each object that needs to be verified according to the user's instructions.

[0043] From the perspective of the data evidence requester, in the method embodiments provided herein, the data evidence requester can pre-request the evidence service platform to build a dedicated verification system for it. Subsequently, the evidence service platform can submit the data to be stored to the evidence service platform through the evidence storage interface provided to the data evidence requester. The evidence service platform can then verify the data to be stored by invoking the verification system dedicated to the evidence requester and store the data.

[0044] In practical applications, the party requesting data attestation isn't necessarily the producer of the data to be attested. In some embodiments, the party requesting data attestation may be an independent software developer (ISV), which interfaces with at least one data producer. The ISV leverages the verification and attestation capabilities of the attestation service platform to provide data attestation services to each data producer. Each data producer is unaware of the attestation service platform behind the ISV. Each data producer submits its own data to be attested to the ISV, which then submits the data to be attested to the attestation service platform.

[0045] In one or more embodiments of the present specification, the set of general verification components deployed on the evidence storage service platform actually represents various pre-developed verification capabilities, each of which can be used to verify at least one data type.

[0046] Specifically, each verification component can be capable of verifying the value of a field of at least one data type, where the data type can specifically represent the type of data content. In a data structure, a field can correspond to a type of data content, and the field value is the data content itself, such as location, time, etc.

[0047] The verification capabilities of the verification component may specifically include: obtaining real information in advance or in real time for local verification; or verifying data format, data value range, etc.

[0048] A collection of general verification components is typically developed by the evidence storage service platform. For example, in scenarios where verification is authenticity, the evidence storage service platform can apply for access to the third party that stores real information. Based on this access, the third party's real information is pre-obtained and stored locally, and a component is developed to compare the input data with the real information. Alternatively, a component can be developed that uses real information access permissions to obtain real information from a third party in real time for comparison and verification of input data.

[0049] The following is a detailed explanation of a method for constructing a data verification system provided in this specification in conjunction with the accompanying drawings.

[0050] like Figure 1 The figure shows a flow chart of a method for constructing a data verification system provided in this specification. This method can be applied to a proof storage service platform.

[0051] The evidence storage service platform can be configured with a general template for defining fields and a set of general verification components, each of which can have the ability to verify the field value of at least one data type.

[0052] The evidence storage service platform can be connected to at least one data evidence storage demander, and the method flow can be used to build a data verification system for the data to be stored by the target evidence storage demander.

[0053] It should be noted that this method flow explains the process of building a data verification system for a single data evidence demander (i.e., the target evidence demander). It can be understood that a data verification system can also be built for other data evidence demanders based on the same steps.

[0054] The method may include at least the following steps.

[0055] S101: The evidence storage service platform provides a verification requirement configuration interface to the target evidence storage demander.

[0056] In an optional embodiment, the target evidence storage demander may include an independent software developer (ISV). The ISV may connect with at least one data producer and provide them with a data verification solution. The ISV can utilize the evidence storage service platform described in this method for development. The data to be stored can be produced by any data producer.

[0057] The configuration interface can be used to define one or more fields based on a common template, and for at least one defined field, select a verification component from a set of common verification components for verifying the field.

[0058] Specifically, the target evidence demander may receive a general template and a general verification component set sent by the evidence service platform through the configuration interface, and then the template evidence demander may perform operations such as defining fields and selecting verification components, and send the defined one or more fields, the selected verification components and the corresponding verified fields to the evidence service platform through the configuration interface.

[0059] Optionally, providing a configuration interface may specifically be providing a visual interface, which may include a general template and a general verification component set. Through the interface configured for the visual interface, the graphical operation results of the target evidence demander on the visual interface are sent to the evidence service platform.

[0060] The graphical operation may specifically include dragging a specified field to a verification component specified in the general verification component set for verifying the field for one or more defined fields, thereby selecting the verification component for verifying the field.

[0061] Obviously, graphical operations can lower the operational threshold and difficulty for parties in need of data evidence storage.

[0062] Optionally, the configuration interface can be a data interaction interface between the target evidence demander and the evidence service platform, used to interact with general templates, general verification component sets, defined fields, and selected verification components.

[0063] The general verification component set can be configured as follows: Take, for example, a case where the verification component is developed based on a third-party verification provider with verification capabilities.

[0064] Optionally, the evidence storage service platform can receive verification service access applications submitted by multiple third-party verification parties. Different third-party verification parties may have the ability to verify field values of different data types. For example, there may be capabilities for verifying location data and others for verifying transaction data. For each third-party verification party, at least one verification component is generated and configured based on the verification capabilities of the third-party verification party.

[0065] Optionally, the evidence storage service platform can apply for real information access permissions (i.e., the ability to conduct verification) from multiple third-party verification parties. If the application is successful, one or more verification components are generated and configured for each permission. The verification component can use the real information access permissions to obtain the real information of the third-party verification party in advance or in real time and then conduct verification.

[0066] S102: The evidence storage service platform creates a custom data structure for the target evidence storage demander's data to be stored according to the target evidence storage demander's operation based on the configuration interface, and determines the fields with verification requirements and the corresponding verification components in the custom data structure.

[0067] Among them, the operations of the target evidence demander based on the configuration interface include: defining one or more fields based on a general template, and for at least one defined field, selecting a verification component for verifying the field from a set of general verification components.

[0068] Based on all the fields defined in the operation, the evidence storage service platform can create a custom data structure. The fields selected for verification in the operation can be determined as the fields in the custom data structure that require verification. Furthermore, based on the verification components determined in the operation, the verification components corresponding to the fields requiring verification are obtained.

[0069] S103: The evidence storage service platform builds a data verification system based on the created custom data structure, the fields with verification requirements, and the corresponding verification components, and returns the call identifier used to call the data verification system to the target evidence storage demander.

[0070] The constructed data verification system can be used to obtain field values that have verification requirements from the custom data structure, call the verification capabilities of the corresponding verification components, and verify the obtained field values.

[0071] Since the operations performed by the different verification systems are essentially the same, including extracting data and calling verification components for verification, the evidence storage service platform can optionally be built based on the same pre-configured basic verification system template to further save development costs.

[0072] Among them, the evidence service platform can develop a universal basic verification system template. For different evidence demanders, different customized information, such as custom data structures, fields with verification requirements and corresponding verification components, can be filled into the universal basic verification system template, thereby building a customized verification system for verifying the data to be stored by the evidence demander.

[0073] Obviously, for different evidence storage demanders, the evidence storage service platform can reuse the basic verification system template to build the system. On the one hand, it only needs to develop the basic verification system template once, saving development costs. On the other hand, it can fill in customized information based on the template to quickly build a customized verification system, thereby improving development efficiency.

[0074] For ease of understanding, in a specific example, the basic verification system template can be a code template to be filled in at the code level. The code template itself cannot be run directly, and requires filling in some data to obtain executable code so that the code can achieve specific functions when run.

[0075] The following is a pseudo code example of a code template for extracting data: determine a data structure where 'data structure unique identifier'=(); and query the data structure for a field value where 'field name'=().

[0076] The bracketed portion can be filled with data based on the actual situation to generate executable code. For example, determine a data structure with 'Data Structure Unique Identifier' = '001' and query the field value where 'Field Name' = 'Vehicle Location' within that data structure. This code, when run, can extract the specified data from the business data.

[0077] However, the specific representation of attribute information contained in fields and data structures may vary across different business data sources. For example, a field name may be represented as either 'field name' or 'code' in different business data; a data structure's unique identifier may be represented as either 'uniqueID' or 'structID' in different business data sources.

[0078] However, when developing basic verification system templates, the evidence storage service platform often struggles to understand the specific representations of the attribute information contained in the fields and data structures of different evidence storage demanders. Instead, the platform develops basic verification system templates based on custom representations. For example, a data structure where 'uniqueID' = () is identified; within this data structure, a field value where 'code' = () is searched.

[0079] Obviously, if the representation of attribute information contained in the fields and data structures of the evidence requester's data to be stored differs from that in the basic verification system template, the constructed verification system will be unable to process the data to be stored. For example, if the data to be stored uses 'structID' to represent the unique identifier of the data structure, the value of its 'uniqueID' cannot be determined, and thus the data to be stored cannot be processed.

[0080] Therefore, in the method provided in this specification, the general template for defining fields can be further utilized to redefine the business data of different evidence demanders, unify the attribute information representation of the fields of the business data, and further unify the attribute information representation of the data structure of each business data so that it is the same as the attribute information representation of the basic verification system template, so that the verification system built based on the basic verification system template can verify the business data of different evidence demanders, saving development costs.

[0081] To facilitate further understanding, a specific example is given below.

[0082] A general template can be {idx:(); code:(); type:(); required:(); maxSize:(); minSize:()}, where idx is the field's unique identifier, code is the field name, type is the field's data type, required indicates whether the field is required, maxSize is the maximum value allowed for the field, and minSize is the minimum value allowed for the field. Some attributes can be omitted.

[0083] This general template can be used to define the attribute information representation of a field. The data storage party can fill in the bracketed part with data to define one or more fields.

[0084] The following is an example of three fields defined based on the general template above.

[0085] {idx: '001'; code: 'companyName'; type: 'String'; required: 'True'}; {idx: '002'; code: 'companyID'; type: 'String'; re required: 'True'; maxSize: '100'; minSize: '0'}; {idx: '003'; code: 'companyLocation'; type: 'String'; required: 'True'}.

[0086] After the data evidence demander defines the above three fields, they can send it to the evidence service platform. The evidence service platform fills these three fields and some information into a data structure template.

[0087] The data structure template can be specifically {uniqueID: (); version: (); author: (); createTime: (); dataItems: ()}. UniqueID represents the unique identifier of the data structure, version represents the version number of the data structure, author represents the creator of the data structure (which can be the party requesting data notarization), createTime represents the creation time of the data structure, and dataItems represents the data content contained in the data structure, which can include one or more fields.

[0088] After being populated, the data structure can be {uniqueID:'001';version:'1.1';author:'Tom';createTime:'20210201';dataItems:"{idx:'001';code:'companyName';type:'String';required:'True'};{idx:'002';code:'companyID';type:'String';required:'True';maxSize:'100';minSize:'0'};{idx:'003';code:'companyLocation';type:'String';required:'True'}"}.

[0089] Obviously, for different data to be recorded represented by attribute information with unified fields and data structures, the record service platform can use the basic verification system template to build a verification system and conduct verification.

[0090] Typically, the data verification system can be deployed on the evidence storage service platform, thereby facilitating the invocation of the local verification component of the evidence storage service platform. In this embodiment, the evidence storage service platform may include multiple data verification systems, which can be distinguished by invocation identifiers.

[0091] Correspondingly, the call identifier may specifically be a unique identifier of the custom data structure, so that the corresponding custom data structure and the corresponding data verification system can be uniquely determined according to the identifier.

[0092] The call identifier can also be a unique identifier for the data verification system, allowing it to be uniquely identified among multiple data verification systems deployed locally on the evidence storage service platform. During subsequent verification, the data evidence requester can send the call identifier along with the business data to be stored to the evidence storage service platform, allowing the data verification system to be identified based on the call identifier.

[0093] In addition, the verification system can also be deployed outside the evidence service platform.

[0094] For example, the data verification system can be deployed on the data evidence demander, and the business data to be evidenced can be directly verified. If multiple data verification systems are deployed on the same data evidence demander, they can be distinguished by calling identifiers. More specifically, the data evidence demander can directly call the locally deployed, corresponding data verification system based on the calling identifier to verify the business data to be evidenced. Among them, when the verification component is used for verification, since the verification component can be deployed on the evidence service platform, the business data to be evidenced needs to be sent to the verification component in the evidence service platform for verification. Optionally, when the data verification system is deployed on the data evidence demander, the verification component can also be deployed on the data evidence demander, so that the business data does not need to be sent to the evidence service platform for verification.

[0095] For example, in an embodiment where the evidence storage service platform utilizes a blockchain network for data storage, a data verification system can also be deployed within the blockchain network. For example, a verification smart contract can be generated based on the constructed custom data structure, the fields requiring verification, and the corresponding verification components, and then deployed to the blockchain network. The verification smart contract can obtain verification capabilities by invoking the verification components of the evidence storage service platform.

[0096] The verification system based on smart contracts can realize the reliable distributed verification of evidence data by the blockchain network, thereby improving the credibility of the data verification system.

[0097] Correspondingly, the call identifier can include: the chain identifier corresponding to the blockchain network, and the association relationship between the contract identifier corresponding to the verification smart contract deployed on the blockchain network. Using this call identifier, you can first determine a blockchain based on the chain identifier, and then determine the corresponding verification smart contract on that blockchain based on the contract identifier.

[0098] Of course, when the blockchain network includes only one blockchain, the call identifier can only include the contract identifier corresponding to the verification smart contract.

[0099] In the above method, the evidence storage requester can leverage the pre-deployed universal templates and universal verification component set on the evidence storage service platform to customize the data structure for the data to be stored. They can also select the verification component used to verify at least one field in the data structure, thereby specifying the business scenario-specific configurations required to build the verification system. The evidence storage service platform can then build a dedicated data verification system for the evidence storage requester based on the business scenario-specific configurations specified by the evidence storage requester.

[0100] The Evidence Storage Service Platform has pre-deployed a set of common templates and common verification components as the foundational technical infrastructure for building verification systems. Evidence requesters only need to specify the relevant business scenario configurations based on this infrastructure, and the Evidence Storage Service Platform will then build a dedicated verification system for them. This avoids duplication of effort when different evidence requesters develop their own verification systems. For example, duplication of effort, such as the ability to verify the same information, is required for each requester, reducing the workload and development costs.

[0101] In addition, any data notarization demander, with the help of the notarization service platform, only needs to determine the fields and customized information such as the verification components used to verify the fields, and the notarization service platform can build a customized data verification system, which greatly simplifies the operations of the data notarization demander.

[0102] Furthermore, parties who demand data notarization can utilize the graphical operations of the visual interface to further lower the threshold and difficulty of operation, without the need to understand programming knowledge, making operations more convenient for parties who demand data notarization.

[0103] In addition, in order to improve verification efficiency, the evidence service platform can also provide some simple data screening logic, which will be added to the data verification system after being specified by the data evidence demander, so that the business data to be evidenced can continue subsequent verification only after passing the data screening.

[0104] Simple data filtering logic can include restricting the format of a field value or the value range of a field. Specifically, it can restrict the format of location data to latitude and longitude, or restrict the value range of transaction data to 0-50,000.

[0105] The party demanding data notarization can specify the format or value range. The notarization service platform will generate the corresponding data screening logic and add it to the data verification system to facilitate verification of business data that has passed the screening. For business data that has not passed the screening, it can be directly determined that the data is untrue without the need for subsequent verification, which can improve verification efficiency.

[0106] This specification also provides an application example. Figure 2 The figure below is a schematic diagram of the principle of a data verification system construction method provided in this specification. It includes users, a proof service platform, and a blockchain network.

[0107] The Evidence Storage Service Platform provides users with a visual interface that includes common templates and all verification components deployed on the Evidence Storage Service Platform.

[0108] The user can enter multiple business-related fields in the general template in the visual interface and specify some verification components to verify some of the entered fields.

[0109] The evidence storage service platform receives the user's operation results through the configuration interface in the visual interface, generates a custom data structure based on the multiple fields entered, and generates a verification smart contract based on the custom data structure, the specified verification component, and the part of the fields to be verified in the custom data structure. The verification smart contract is deployed to the blockchain network, and the contract identifier is received and returned to the user. The contract identifier can be used to call the verification smart contract.

[0110] Based on the data verification system constructed by the above method flow, this specification also provides a data verification method.

[0111] like Figure 3 FIG2 is a flow chart of a data verification method provided in this specification. The method may include at least the following steps.

[0112] S201: The evidence storage service platform receives a data evidence storage request.

[0113] The data attestation request specifies the data to be attested and the call identifier used to call the data verification system.

[0114] The call identifier can be received by the data evidence demander after building a data verification system on the evidence service platform.

[0115] S202: The evidence storage service platform calls the corresponding data verification system based on the call identifier specified in the data evidence storage request.

[0116] Based on the explanation of the data verification system construction method process above, the call identifier can be a unique identifier of the data verification system. Optionally, the evidence storage service platform can uniquely identify a corresponding data verification system among multiple data verification systems based on the call identifier.

[0117] The call identifier may also include an association between the chain identifier and the contract identifier. Optionally, the data verification system can be deployed as a smart contract on a blockchain network. The evidence storage service platform can submit a transaction based on the data to be stored to the blockchain network corresponding to the chain identifier. This transaction is used to invoke the verification smart contract corresponding to the contract identifier to verify the data to be stored.

[0118] S203: The called data verification system verifies the data to be stored specified in the data storage request.

[0119] Among them, the specific verification of the data to be stored may include: based on the custom data structure configured in the data verification system and the fields with verification requirements, parsing the field values of the fields with verification requirements from the data to be stored, and calling the corresponding verification component to verify the parsed field values.

[0120] In the above method, if the data to be stored passes the verification, the data to be stored can be stored. For example, if the verification result indicates that it passes, the data to be stored is packaged into a transaction and submitted to the blockchain network for storage.

[0121] Of course, in some embodiments, it's possible to directly store the data and verification results without worrying about whether they've been verified. For example, the evidence storage service platform can obtain verification results from a data verification system; the evidence storage service platform then packages the data and verification results into a transaction and submits it to the blockchain network for storage. Subsequent data storage requesters can then verify the authenticity of the data based on the verification results.

[0122] When storing specific data, it is usually possible to store the data to be stored on the blockchain network. Of course, it is also possible to store the data to be stored centrally. This specification does not limit the method of storing data.

[0123] It's important to note that in embodiments where a verification smart contract is used to verify the data to be stored, the data to be stored must be encapsulated into a transaction and further stored on the blockchain network in order to run the smart contract. Regardless of whether the verification smart contract's verification result indicates a pass or fail, the blockchain network will write the transaction containing the data to be stored to the blockchain and also anchor the verification result corresponding to the transaction to the blockchain.

[0124] In addition, in an embodiment where data is stored on a blockchain and a verification system is constructed using smart contracts, the blockchain used for storing the data may not be the same blockchain as the blockchain used for deploying the smart contract.

[0125] For example, the evidence storage service platform can encapsulate the data to be stored in a first transaction and store it in the first blockchain. It then uses the call identifier (specifically, the contract identifier) and the summary of the first transaction to encapsulate it into a second transaction, sends the second transaction to the blockchain network that maintains the second blockchain, and then calls the verification smart contract deployed in the second blockchain. The verification smart contract obtains the first transaction in the first blockchain across the chain, and then obtains the data to be stored for verification. In this way, the data to be stored is actually stored in the first blockchain, and the verification results are stored in the second blockchain.

[0126] Regarding the data to be stored in the aforementioned method, since it may be the business data of the party requesting the data storage, it may be subject to confidentiality requirements to prevent other problems caused by business data leakage. For example, some business data may contain private data, and leaking private data may cause losses to the party requesting the data storage.

[0127] In an optional embodiment, in order to protect the data to be stored from being leaked, the device where the data verification system is located can be set up with a trusted execution area.

[0128] The trusted execution area can have independent computing resources and storage areas, the computing process therein will not be leaked, and the input and output of data in the trusted execution area are strictly restricted. The trusted execution area can be used to verify the data, so that the plaintext of the data to be stored cannot be leaked to the data verification system.

[0129] Furthermore, the trusted execution zone can have independent public and private keys, and the data verification system cannot obtain the private key of the trusted execution zone. Specifically, the data verification system can generate the public and private keys in the trusted execution zone in advance and retain the private key in the trusted execution zone.

[0130] The data to be stored may include: ciphertext of the data to be stored obtained by encrypting the plaintext of the data to be stored using the public key of the trusted execution zone.

[0131] Correspondingly, the data verification system verifies the data to be stored, which may include: decrypting the ciphertext of the data to be stored within the trusted execution area to obtain the plaintext of the data to be stored; and verifying the plaintext of the data to be stored within the trusted execution area. Specifically, the verification component may be called within the trusted execution area to verify the plaintext of the data to be stored.

[0132] Before and after the entire verification process, the data verification system cannot obtain the plaintext of the data to be stored.

[0133] In addition, if the data to be stored needs to be sent to the blockchain network for storage, since the data in the blockchain network is public, the stored data also needs to be encrypted.

[0134] Optionally, the plaintext of the data to be stored can be encrypted in the trusted execution area using the public key of the party requesting the data storage, and the encrypted ciphertext can be stored in the blockchain network, so that only the party requesting the data storage can decrypt the ciphertext in the blockchain network to obtain the plaintext of the data to be stored.

[0135] Alternatively, the plaintext data to be attested can be encrypted within the trusted execution zone using the blockchain network's public key, and the encrypted ciphertext stored on the blockchain network. Subsequent data attestation parties who need to use the attested data can request the blockchain network to decrypt the ciphertext and obtain the plaintext data to be attested.

[0136] In addition to the above method flow, this specification also provides two device embodiments.

[0137] Device embodiment 1.

[0138] like Figure 4 The figure shows a schematic diagram of a data verification system construction device provided in this specification. This device can be applied to a proof service platform. The proof service platform can be configured with a universal template for defining fields and a universal verification component set. Each verification component can be capable of verifying field values of at least one data type. The proof service platform can be connected to at least one data proof demander, and the device can be used to build a verification system for the target proof demander's data to be stored.

[0139] The device may specifically include the following units.

[0140] Interface providing unit 301: used to provide a verification requirement configuration interface to the target evidence storage demander, the configuration interface is used to: define one or more fields based on a general template, and for at least one defined field, select a verification component from a general verification component set for verifying the field.

[0141] Verification requirement definition unit 302: used to create a custom data structure for the target evidence demander's data to be stored based on the target evidence demander's operation based on the configuration interface, and determine the fields with verification requirements and corresponding verification components in the custom data structure.

[0142] Verification system construction unit 303: used to build a data verification system based on the created custom data structure, fields with verification requirements and corresponding verification components, and return the call identifier used to call the data verification system to the target evidence demander.

[0143] Among them, the target evidence demanders may include: independent software developers ISV; ISV can connect to at least one data producer, and the data to be evidenced can be data produced by any data producer.

[0144] The configuration method of a general verification component set may include: receiving verification service access applications submitted by multiple verification third parties respectively; different verification third parties have the ability to verify field values of different data types; for each verification third party, configuring at least one verification component based on the verification capability of the verification third party.

[0145] The verification system construction unit 303 can be specifically configured to generate a verification smart contract based on the constructed custom data structure, fields requiring verification, and corresponding verification components, and deploy the verification smart contract to the blockchain network. The verification smart contract obtains verification capabilities by invoking the verification component of the evidence storage service platform. Accordingly, the invocation identifier can include the chain identifier corresponding to the blockchain network and an association with the contract identifier corresponding to the verification smart contract deployed on the blockchain network.

[0146] For other explanations of the embodiment of this device, please refer to the above method flow.

[0147] Device embodiment 2.

[0148] like Figure 5 The figure shows a schematic diagram of the structure of a data verification device provided in this specification. The device can be applied to a proof storage service platform and specifically includes the following units.

[0149] Receiving unit 401 is used to receive a data evidence storage request. The data evidence storage request specifies the data to be stored and a call identifier for calling a data verification system.

[0150] The calling unit 402 is used to call the corresponding data verification system to verify the specified data to be stored based on the specified calling identifier.

[0151] Verifying the specified data to be stored may include: parsing the field values that need to be verified from the data to be stored based on the custom data structure configured in the data verification system and the fields that need to be verified, and calling the corresponding verification component to verify the parsed field values.

[0152] The data verification system may have a trusted execution zone, in which the data verification system may pre-generate a public key and a private key, and retain the private key within the trusted execution zone. The data to be stored may include ciphertext of the data to be stored, obtained by encrypting the plaintext data to be stored using the public key of the trusted execution zone.

[0153] Verifying the designated data to be stored may specifically include: decrypting the ciphertext of the data to be stored in the trusted execution area to obtain the plaintext of the data to be stored; and verifying the plaintext of the data to be stored in the trusted execution area.

[0154] In the case where the calling identifier includes an association between a chain identifier and a contract identifier, the calling unit 402 can be specifically used to: submit to the blockchain network corresponding to the chain identifier: a transaction encapsulated based on the data to be stored; the transaction is used to call the verification smart contract corresponding to the contract identifier to verify the data to be stored.

[0155] The calling unit 402 can also be used to: obtain the verification results from the data verification system; encapsulate the data to be stored and the verification results into a transaction and submit it to the blockchain network; or, if the verification results are qualified, encapsulate the data to be stored into a transaction and submit it to the blockchain network.

[0156] For other explanations of the embodiments of the present device, reference may be made to the above method flow.

[0157] An embodiment of this specification also provides a computer device, which includes at least a memory, a processor, and a computer program stored in the memory and runnable on the processor, wherein when the processor executes the program, it implements a method for constructing a data verification system, or an operation performed by an evidence service platform in a data verification method.

[0158] Figure 6 10 is a schematic diagram showing a more specific hardware structure of a computer device provided in an embodiment of this specification. The device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are connected to each other within the device via the bus 1050.

[0159] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0160] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage devices, dynamic storage devices, etc. The memory 1020 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0161] The input / output interface 1030 is used to connect input / output modules to implement information input and output. The input / output modules can be configured as components within the device (not shown in the figure) or can be externally connected to the device to provide corresponding functions. Input devices may include a keyboard, mouse, touch screen, microphone, various sensors, etc., and output devices may include a display, speaker, vibrator, indicator light, etc.

[0162] The communication interface 1040 is used to connect to a communication module (not shown) to enable communication between the device and other devices. The communication module can communicate via a wired method (such as USB, network cable, etc.) or a wireless method (such as mobile network, WiFi, Bluetooth, etc.).

[0163] The bus 1050 comprises a pathway for transmitting information between the various components of the device (eg, the processor 1010 , the memory 1020 , the input / output interface 1030 , and the communication interface 1040 ).

[0164] It should be noted that although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040, and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, it will be understood by those skilled in the art that the above device may only include the components necessary to implement the embodiments of this specification, and does not necessarily include all the components shown in the figure.

[0165] An embodiment of this specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a method for constructing a data verification system, or an operation performed by an evidence storage service platform in a data verification method.

[0166] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0167] Through the description of the above implementation methods, it can be known that those skilled in the art can clearly understand that the embodiments of this specification can be implemented by means of software plus a necessary general hardware platform. Based on this understanding, the technical solutions of the embodiments of this specification, or the part that contributes to the prior art, can be embodied in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or certain parts of the embodiments of this specification.

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

[0169] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. The device embodiment described above is merely illustrative, wherein the modules described as separate components may or may not be physically separated, and when implementing the embodiment scheme of this specification, the functions of each module can be implemented in the same one or more software and / or hardware. It is also possible to select some or all of the modules according to actual needs to achieve the purpose of the embodiment scheme. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0170] The above is only a specific implementation of the embodiment of this specification. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the embodiment of this specification. These improvements and modifications should also be regarded as protection for the embodiment of this specification.

Claims

1. A method for constructing a data verification system, applied to a proof storage service platform. The proof storage service platform is configured with a universal template for defining fields and a set of universal verification components, each of which is capable of verifying the authenticity of field values of at least one data type. The proof storage service platform is connected to at least one data proof storage requester, each of which has a data proof storage requester's data verification requirement. The method is used to construct a verification system for the target proof storage requester's data to be stored. The method comprises: Providing a verification requirement configuration interface to the target evidence storage requester, wherein the configuration interface is used to: enable the target evidence storage requester to define one or more fields based on the general template, and, for at least one defined field, select a verification component from the general verification component set for verifying the field; Creating a custom data structure for the target evidence storage requester's data to be stored based on the configuration interface according to the target evidence storage requester's operation, and determining the fields with verification requirements and corresponding verification components in the custom data structure; Based on the created custom data structure, the fields with verification requirements, and the corresponding verification components, a verification smart contract is generated as a data verification system, and the verification smart contract is deployed to the blockchain network; wherein, the verification smart contract is used to verify the data to be stored that has been stored in the blockchain network.

2. The method of claim 1, further comprising: after deploying the verification smart contract to the blockchain network: The data verification system and / or the calling identifier for calling the data verification system are returned to the target evidence demander.

3. The method as described in claim 1, wherein the verification smart contract is used to store the verification results in the blockchain network.

4. The method of claim 1, further comprising: Adding the data screening logic specified by the target evidence demander to the data verification system; The verification smart contract is used to verify the data to be stored after being filtered by the data screening logic.

5. The method according to claim 1, wherein the verification requirement configuration interface comprises a visual interface; the visual interface comprises the general template and the general verification component set; The operation according to the target evidence storage demander based on the configuration interface includes: According to the target evidence demander's graphical operation based on the visual interface.

6. The method of claim 1, wherein a verification smart contract is generated as a data verification system based on the created custom data structure, the fields requiring verification, and the corresponding verification components, including: Fill the created custom data structure, fields with verification requirements, and corresponding verification components into the general basic verification system template to generate a verification smart contract as the data verification system.

7. The method according to claim 1, wherein the target evidence storage requester comprises: Independent software developers (ISVs); The ISV is connected to at least one data producer, and the data to be stored is data produced by any data producer.

8. The method of claim 1, wherein the general verification component set is configured as follows: Receive verification service access applications submitted by multiple third-party verification parties; different third-party verification parties have the ability to verify field values of different data types; For each third-party verification party, at least one verification component is configured based on the verification capability of the third-party verification party.

9. According to the method of claim 1, the verification smart contract obtains verification capabilities by calling the verification component of the evidence storage service platform.

10. The method according to claim 2, wherein the calling identifier comprises: The association relationship between the chain identifier corresponding to the blockchain network and the contract identifier corresponding to the verification smart contract deployed on the blockchain network.

11. A data verification method, comprising: The evidence storage service platform receives the data evidence storage request; The data evidence storage request specifies the data to be stored and a call identifier for calling the data verification system; The evidence storage service platform calls the corresponding data verification system based on the specified call identifier; The called data verification system verifies the specified data to be stored, including: based on the custom data structure configured in the data verification system and the fields with verification requirements, parsing the field values with verification requirements from the data to be stored, and calling the corresponding verification component to verify the parsed field values.

12. The method of claim 11, wherein the data verification system has a trusted execution zone, the data verification system pre-generates a public key and a private key in the trusted execution zone, and retains the private key in the trusted execution zone; The data to be stored as evidence includes: ciphertext of the data to be stored as evidence obtained by encrypting the plaintext of the data to be stored as evidence using the public key; The data verification system verifies the data to be stored, including: Decrypting the ciphertext of the data to be stored as evidence in the trusted execution area to obtain the plaintext of the data to be stored as evidence; In the trusted execution area, the plaintext of the data to be stored is verified.

13. The method according to claim 11, wherein the calling identifier comprises: The relationship between the chain identifier and the contract identifier; The evidence storage service platform calls the corresponding data verification system based on the call identifier, including: The evidence storage service platform submits to the blockchain network corresponding to the chain identifier: a transaction encapsulated based on the data to be stored; The transaction is used to call the verification smart contract corresponding to the contract identifier to verify the data to be stored.

14. The method of claim 11, further comprising: The evidence storage service platform obtains the verification result from the data verification system; The evidence storage service platform packages the data to be stored and the verification result into a transaction and submits it to the blockchain network; Alternatively, if the verification result indicates that the data to be stored is passed, the data to be stored is packaged into a transaction and submitted to the blockchain network.

15. A data verification system construction device, applied to a proof storage service platform. The proof storage service platform is configured with a universal template for defining fields and a set of universal verification components, each verification component capable of verifying field values of at least one data type. The proof storage service platform is connected to at least one data proof storage requester, each of which has a data proof storage requester's data verification requirement. The device is used to construct a verification system for the target proof storage requester's data to be stored. The device comprises: An interface providing unit is configured to provide a verification requirement configuration interface to the target evidence storage requester, wherein the configuration interface is configured to enable the target evidence storage requester to define one or more fields based on the general template, and to select, for at least one defined field, a verification component from the general verification component set for verifying the field; A verification requirement definition unit is configured to create a custom data structure for the target evidence storage requester's data to be stored based on the operation of the target evidence storage requester based on the configuration interface, and to determine the fields with verification requirements and corresponding verification components in the custom data structure; Verification system construction unit: used to generate a verification smart contract as a data verification system based on the created custom data structure, fields with verification requirements and corresponding verification components, and deploy the verification smart contract to the blockchain network; wherein, the verification smart contract is used to verify the data to be stored that has been stored in the blockchain network.

16. A data verification device, based on the data verification system constructed by the data verification system construction device according to claim 15, applied to an evidence storage service platform; the device comprising: Receiving unit: used to receive data evidence storage request; The data evidence storage request specifies the data to be stored and a call identifier for calling the data verification system; Calling unit: used to call the corresponding data verification system to verify the specified data to be stored based on the specified calling identifier. The verification of the specified data to be stored includes: based on the custom data structure configured in the data verification system and the fields with verification requirements, parsing the field values with verification requirements from the data to be stored, and calling the corresponding verification component to verify the parsed field values.

17. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the functions of the evidence storage service platform as described in any one of claims 1 to 14 are realized.

Images