Structured data consistency verification method

Abstract

The invention relates to the technical field of data management, in particular to a structured data consistency verification method, and provides a new method for verifying the consistency of structured data by combining DID, an oracle machine and a block chain technology. By introducing the oracle machine, the external data can be introduced into the block chain system for verification, so that the credibility and consistency of the data are ensured. The method provides a new technical support for constructing a safer and more credible data sharing and exchanging platform, and is expected to bring great innovation and breakthrough in the traditional data management field.

Description

Technical Field

[0001] The present invention relates to the technical field of data management, and in particular to a method for verifying the consistency of structured data. Background Art

[0002] In the field of traditional data management, data consistency, security and credibility have always been important challenges. Traditional data exchange and sharing platforms often face data tampering, forgery and security issues, which limit the reliability and practicality of data. In addition, data verification and auditing are also difficult points in traditional data management, especially in data exchange scenarios involving multiple parties.

[0003] As a decentralized and tamper-proof distributed ledger technology, blockchain technology has been widely used in the field of data management. Blockchain provides a new solution for data security and credibility through its decentralized and tamper-proof characteristics. It can ensure the integrity and consistency of data while providing traceable data auditing functions.

[0004] As a decentralized identification method, DID can provide data subjects with a unique identity and protect the privacy and security of data subjects.

[0005] Oracle is a bridge between blockchain and external data sources. It can introduce external data into the blockchain network. Oracle obtains external data in a variety of ways and submits it to the blockchain for verification and storage. The introduction of oracle enables the blockchain system to obtain and verify external data, thereby expanding the application scenarios of blockchain. Summary of the invention

[0006] In view of this, an object of the present invention is to provide a structured data consistency verification method to overcome the problems existing in the current prior art.

[0007] To achieve the above objectives, the present invention adopts the following technical solutions:

[0008] This application provides a structured data consistency verification method, including:

[0009] The third-party trusted service Service calls the smart contract to obtain the random factor, and stores the random factor locally in the App application;

[0010] Using the random factor, the App performs hash calculation on each field value of the newly added or updated data, and uses the hash value of each field value to calculate the Merkle tree root hash;

[0011] The hash value of each field value and the Merkle tree root hash are stored in the blockchain in the form of logs through the third-party trusted service Service, and information and contract events are returned; wherein the returned information and contract events at least include: events, current block height and transaction flags;

[0012] Calling the Web business service Service interface through the App application to write the data to be added or updated to the data storage device on the Web business service Service side;

[0013] The data consumer or verifier obtains the user's data through the Web business Service and calls the third-party trusted service Service to verify the consistency of the data.

[0014] Furthermore, in the above method, the method of obtaining the random factor by calling the smart contract through the third-party trusted service Service includes:

[0015] Create a DID user identity;

[0016] According to the DID user identity, query whether there is a random factor, and if so, return the random factor;

[0017] If not, generate a random factor and encrypt the random factor using the user's public key to form a ciphertext;

[0018] Persistently store the mapping relationship between ciphertext and DID mark and return the ciphertext.

[0019] Furthermore, in the above method, storing the random factor locally in the App application includes:

[0020] The user enables the delegation mode of the App application and requests the third-party trusted service to keep the random factor.

[0021] Furthermore, the method described above, wherein the hash value of each field value and the Merkle tree root hash are stored in the blockchain in the form of a log through the third-party trusted service Service, includes:

[0022] Monitor the smart contract BusinessContract event EventDataID; wherein the parameters of the event EventDataID include at least: hash array, number of hash array elements and block height;

[0023] The solidifyEvidences interface of the smart contract BusinessContract is called, wherein the parameters of the interface solidifyEvidences include at least: a hash array and the number of elements in the hash array.

[0024] Furthermore, the above method, the returned information and the contract event include:

[0025] Parse the monitored EventDataID event, and store the event, block_height block height, transaction_index transaction index in the block, and log_index log index in the transaction persistently;

[0026] The block_height block height in the event, the transaction_index transaction index in the block, and the log_index log index in the transaction are returned to the App application.

[0027] Furthermore, in the method described above, the App application calls the Web business service Service interface to write the data to be added or updated to the data storage device on the Web business service Service side, including:

[0028] The request for the business interface needs to carry block_height, transaction_index and log_index;

[0029] When data is persisted, the correspondence between data and block_height, transaction_index, and log_index is saved.

[0030] Furthermore, in the above method, the data consumer or verifier obtains the user's data through the Web business Service and calls the third-party trusted service Service to verify the consistency of the data, including:

[0031] Determine whether the identity of the data consumer or verifier is consistent with that of the data creator;

[0032] If they are consistent, a random factor is obtained from the App application;

[0033] Using random factors to calculate the hash of each field value in the user's data obtained from the Web business service Service, and constructing a Merkle root hash of the user data according to the hash value;

[0034] Call the blockchain SDK, obtain block information based on block_height, and use transaction_index and log_index to obtain EventDataID events;

[0035] Parse the EventDataID event, obtain the Merkle tree root hash value, and compare it with the Merkle root hash value of the user data;

[0036] If the values ​​are the same, the data of the Web business service Service has not been tampered with;

[0037] Otherwise, the data has been tampered with, and by further comparing other elements in the hash array in the EventDataID event, the tampered field value can be confirmed.

[0038] Furthermore, in the above method, if the identity of the data consumer or verifier is inconsistent with that of the data creator, the data consumer or verifier obtains the user's data through the Web business Service and calls the third-party trusted service Service to verify the consistency of the data, including:

[0039] The third-party trusted service Service obtains through DID whether the data consumer or verifier has obtained the data authorization of the data creator;

[0040] If authorization is not obtained, the third-party trusted service Service notifies the App application of the user authorization request; wherein the request parameters at least include: data consumer or verifier flag, data consumer or verifier public key, data consumer or verifier contact information and data usage purpose;

[0041] After the authorization is passed, the third-party trusted service Service verifies the authorization information of the data consumer or verifier, and calls the third-party trusted service Service to verify the consistency of the data after the verification is passed.

[0042] Furthermore, in the above method, the third-party trusted service Service notifies the App application of the user authorization request, including:

[0043] The data consumer or verifier creates an authorization request, wherein the authorization request parameters include at least: a DID flag of the requester, a DID flag of the data source creator, data to be consumed or verified, and a request signature;

[0044] The authorization request is sent to the App application, and the App application is notified of the user authorization request through the third-party trusted service Service.

[0045] Furthermore, in the above method, the third-party trusted service Service verifies the authorization information of the data consumer or verifier, including:

[0046] Get the DID from the authorization request src ;

[0047] Using the DID src Get the corresponding DID document information from the blockchain;

[0048] Get the DID from the DID document information src Authorization record information;

[0049] Acquire the applicant's public key information from the authorization record information;

[0050] Use the public key to verify the signature of the authorization request.

[0051] The beneficial effects of the present invention are:

[0052] This application first obtains random factors by calling a smart contract through a third-party trusted service Service, and stores the random factors locally in the App application; hash calculations are performed on the values ​​of each field of the newly added or updated data using the random factors through the App, and the hash values ​​of each field value are used to calculate the Merkle tree root hash; the hash values ​​of each field value and the Merkle tree root hash are stored in the blockchain in the form of logs through the third-party trusted service Service, and information and contract events are returned; wherein the returned information and contract events at least include: events, current block heights, and transaction flags; the Web business service Service interface is called through the App application, and the data to be added or updated is written to the data storage device on the Web business service Service side; the data consumer or verifier obtains the user's data through the Web business Service, and calls the third-party trusted service Service to verify the consistency of the data. In this application, DID, oracle, and blockchain technology are combined to propose a new method to verify the consistency of structured data. By introducing an oracle, external data can be introduced into the blockchain system for verification, thereby ensuring the credibility and consistency of the data. This invention provides new technical support for building a more secure and reliable data sharing and exchange platform, and is expected to bring major innovations and breakthroughs in the field of traditional data management. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the embodiments of the present invention 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 of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0054] Figure 1 It is a flowchart provided by an embodiment of a method for verifying consistency of structured data of the present invention. DETAILED DESCRIPTION

[0055] To make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be described in detail below. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other implementation methods obtained by ordinary technicians in this field without creative work belong to the scope of protection of the present invention.

[0056] Figure 1 It is a flowchart provided by an embodiment of a method for verifying consistency of structured data of the present invention.

[0057] See also Figure 1 , this embodiment may include the following steps:

[0058] S1. Call the smart contract through the third-party trusted service Service to obtain the random factor, and store the random factor locally in the App application;

[0059] S2. Use the random factor to perform hash calculations on each field value of the newly added or updated data through the App, and use the hash values ​​of each field value to calculate the Merkle tree root hash;

[0060] S3. The hash value of each field value and the Merkle tree root hash are stored in the blockchain in the form of logs through the third-party trusted service Service, and information and contract events are returned; wherein the returned information and contract events at least include: events, current block height and transaction flags;

[0061] S4. Call the Web business service Service interface through the App application to write the data to be added or updated to the data storage device on the Web business service Service side;

[0062] S5. The data consumer or verifier obtains the user's data through the Web business Service and calls the third-party trusted service Service to verify the consistency of the data.

[0063] It can be understood that the present application first obtains the random factor by calling the smart contract through the third-party trusted service Service, and stores the random factor locally in the App application; the App uses the random factor to perform hash calculations on the values ​​of each field of the newly added or updated data, and uses the hash value of each field value to calculate the Merkle tree root hash; the hash value of each field value and the Merkle tree root hash are stored in the blockchain in the form of logs through the third-party trusted service Service, and information and contract events are returned; wherein the returned information and contract events include at least: events, current block height and transaction flags; the App application calls the Web business service Service interface, and writes the data to be added or updated to the data storage device on the Web business service Service side; the data consumer or verifier obtains the user's data through the Web business Service, and calls the third-party trusted service Service to verify the consistency of the data. In this application, DID, oracle and blockchain technology are combined to propose a new method to verify the consistency of structured data. By introducing a oracle, external data can be introduced into the blockchain system for verification, thereby ensuring the credibility and consistency of the data. This invention provides new technical support for building a more secure and reliable data sharing and exchange platform, and is expected to bring major innovations and breakthroughs in the field of traditional data management.

[0064] Preferably, the random factor is obtained by calling a smart contract through a third-party trusted service, including:

[0065] Create a DID user identity;

[0066] According to the DID user identity, query whether there is a random factor, and if so, return the random factor;

[0067] If not, generate a random factor and encrypt the random factor using the user's public key to form a ciphertext;

[0068] Persistently store the mapping relationship between ciphertext and DID mark and return the ciphertext.

[0069] It is understandable that the process of obtaining random factors by calling a smart contract through a third-party trusted service mainly includes:

[0070] Call the NonceContract contract requestNonce interface to request a random factor. The parameters include but are not limited to:

[0071] a) DID logo of the contract caller;

[0072] b) A verifiable token.

[0073] The token generation rules are:

[0074] token=signature(PK,DID)

[0075] Among them, PK is the private key of the contract caller.

[0076] c) The interface returns a request flag requestId

[0077] Call the NonceContract getNonce interface to obtain the random factor. The parameters include but are not limited to:

[0078] a) Request flag requestId

[0079] b) The interface returns the random factor ciphertext, which is encrypted using the requester's public key.

[0080] Obtaining random factors through the smart contract NonceContract mainly includes:

[0081] 1. Set the OracleContract address;

[0082] 2. Set the URL address of the oracle service to generate the random factor function;

[0083] 3. The requestNonce interface calls the query method of the Oracle Contract. The method parameters include but are not limited to:

[0084] a) The smart contract NonceContract’s own address;

[0085] b) Generate random factor function URL address;

[0086] The URL address is in the format:

[0087] [https: / / oracle_domain] / v1 / nonce? did=xxx&token=yyy

[0088] The parameter did is the DID flag of the contract caller, and token is a string that verifies the legitimacy of the did identity. https: / / oracle_domain is optional. If specified, the oracle service needs to be processed by an external service, otherwise the oracle service is processed internally.

[0089] c) The method returns the request identifier requestId.

[0090] 4. The resultCallback interface is used to process the random factor returned by the Oracle Contract. The parameters include but are not limited to:

[0091] a) Request flag reqeuestId;

[0092] b) Random factor ciphertext result.

[0093] OracleContract mainly includes:

[0094] 1. Trigger the contract event OracleRequestEvent through the query method. The event includes but is not limited to the following parameters:

[0095] a) Smart Contract NonceContract Address

[0096] b) Request URL

[0097] c) Request flag requestId

[0098] 2. Return the random factor to the smart contract NonceContract through the result method. The parameters include but are not limited to:

[0099] a) Smart Contract NonceContract Address

[0100] b) Request flag requestId

[0101] c) Random factor ciphertext result

[0102] 3. The result method calls back the resultCallback method of the smart contract NonceContract.

[0103] The random factor is obtained by calling the smart contract NonceContract through the third-party trusted service Service. The oracle service includes:

[0104] 1. Monitor the OracleRequestEvent contract event of the OracleContract;

[0105] 2. Obtain the user's DID logo through contract events and verify the legitimacy of the identity;

[0106] 3. Generate or obtain random factors;

[0107] 4. Call the result method of the oracle contract OracleContract.

[0108] The oracle service obtains the user's DID mark through the contract event and verifies the legitimacy of the identity, which mainly includes the following steps:

[0109] 1. Parse the URL from the OracleRequestEvent contract event and obtain the DID flag and token;

[0110] 2. Obtain DID document information from the blockchain through the DID user logo;

[0111] 3. Get the user's public key from the document;

[0112] 4. Use the public key to verify whether the token is legitimate.

[0113] Generate or obtain random factors, mainly including:

[0114] 1. Check whether the user has a random factor (ciphertext) based on the user's DID flag, and return the random factor if it does;

[0115] 2. If not, generate a random factor and encrypt the random factor using the user's public key to form a ciphertext;

[0116] 3. Persistent storage of the mapping relationship between ciphertext and DID mark;

[0117] 4. Return the ciphertext.

[0118] Preferably, the random factor is stored locally in the App application, including:

[0119] The user enables the delegated mode of the App and requests a third-party trusted service to keep the random factor.

[0120] Preferably, the hash value of each field value and the Merkle tree root hash are stored in the blockchain in the form of logs through a third-party trusted service, including:

[0121] Listen to the smart contract BusinessContract event EventDataID; the parameters of the event EventDataID include at least: hash array, number of hash array elements and block height;

[0122] Call the solidifyEvidences interface of the smart contract BusinessContract, where the parameters of the interface solidifyEvidences include at least: a hash array and the number of hash array elements.

[0123] It is understandable that the App application calls the smart contract BusinessContract through the third-party trusted service Service to store the hash of each field value and the Merkle tree root hash in the blockchain in the form of logs. The third-party trusted service Service mainly includes:

[0124] 1. Monitor the smart contract BusinessContract event EventDataID. Event parameters include but are not limited to:

[0125] a) hash[]: hash array, the first element is the Merkle tree root hash, and the others are field value hashes;

[0126] b) hash_size: number of hash array elements;

[0127] c)block_height: block height;

[0128] 2. Call the solidifyEvidences interface of the smart contract BusinessContract. The interface parameters include but are not limited to:

[0129] a) hash[]: hash array, the first element is the Merkle tree root hash, and the others are field value hashes;

[0130] b) hash_size: number of hash array elements;

[0131] Among them, the solidifyEvidences interface will trigger the EventDataID event.

[0132] Preferably, the returned information and contract events include:

[0133] Parse the monitored EventDataID event, and store the event, block_height block height, transaction_index transaction index in the block, and log_index log index in the transaction persistently;

[0134] Return the block_height block height, transaction_index transaction index in the block, and log_index log index in the transaction in the event to the App application.

[0135] It is understandable that the third-party trusted service Service not only stores the return information of the smart contract BusinessContract, including but not limited to event flags and transaction flags, but also mainly includes:

[0136] 1. Parse the monitored EventDataID event, and store the event, block_height block height, transaction_index transaction index in the block, and log_index log index in the transaction persistently;

[0137] 2. Return the block_height block height, transaction_index transaction index in the block, and log_index log index in the transaction in the event to the App application.

[0138] Preferably, step S4 comprises:

[0139] The request for the business interface needs to carry block_height, transaction_index and log_index;

[0140] When data is persisted, the correspondence between data and block_height, transaction_index, and log_index is saved.

[0141] Preferably, step S5 includes:

[0142] Determine whether the identity of the data consumer or verifier is consistent with that of the data creator;

[0143] If they are consistent, the random factor is obtained from the App application;

[0144] Use random factors to calculate the hash of each field value in the user's data obtained from the Web business service Service, and construct the Merkle root hash of the user data based on the hash value;

[0145] Call the blockchain SDK, obtain block information based on block_height, and use transaction_index and log_index to obtain EventDataID events;

[0146] Parse the EventDataID event, obtain the Merkle tree root hash value, and compare it with the Merkle root hash value of the user data;

[0147] If the values ​​are the same, the data of the Web business service Service has not been tampered with;

[0148] Otherwise, the data has been tampered with, and by further comparing other elements in the hash array in the EventDataID event, the tampered field value can be confirmed.

[0149] Preferably, if the identities of the data consumer or verifier are inconsistent with the data creator, step S5 includes:

[0150] The third-party trusted service Service obtains data consumers or verifiers through DID to determine whether they have obtained data authorization from the data creator;

[0151] If authorization is not obtained, the third-party trusted service Service notifies the App application to request the user to authorize the data; the request parameters include at least: data consumer or verifier flag, data consumer or verifier public key, data consumer or verifier contact information and data usage purpose;

[0152] After authorization is passed, the third-party trusted service Service verifies the authorization information of the data consumer or verifier, and calls the third-party trusted service Service to verify the consistency of the data after verification.

[0153] Preferably, the third-party trusted service Service notifies the App application of the user authorization request, including:

[0154] The data consumer or verifier creates an authorization request, where the authorization request parameters include at least: the requester's DID flag, the data source creator's DID flag, the data to be consumed or verified, and the request signature;

[0155] The authorization request is sent to the App application, and the App application is notified of the user's authorization request through the third-party trusted service Service.

[0156] It is understandable that the App application handles the authorization operations of the user, mainly including:

[0157] 1. The first authorization operation creates the DID document information of the data source creator;

[0158] 2. Add the data consumer or verifier’s logo and public key to the DID document;

[0159] 3. DID document information is saved on the chain.

[0160] Requester DID mark, data source creator DID mark, data to be consumed or verified, and request signature

[0161] The way to request a signature is:

[0162] S=signature(PK,Hash(DID apply ,DID src ,DATA))

[0163] Among them, PK is the applicant's private key, DID apply DID mark for applicants, DID src It is the data source creator flag and DATA is the data to be consumed or verified.

[0164] Preferably, the third-party trusted service Service verifies the authorization information of the data consumer or verifier, including:

[0165] Get the DID from the authorization requestsrc ;

[0166] Using DID src Get the corresponding DID document information from the blockchain;

[0167] Get the DID from the DID document information src Authorization record information;

[0168] Obtain the applicant's public key information from the authorization record information;

[0169] Use the public key to verify the signature of the authorization request.

[0170] It can be understood that the same or similar parts of the above embodiments can be referenced to each other, and the contents not described in detail in some embodiments can refer to the same or similar contents in other embodiments.

[0171] It should be noted that, in the description of the present invention, the terms "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or implying relative importance. In addition, in the description of the present invention, unless otherwise specified, the meaning of "plurality" refers to at least two.

[0172] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code that includes one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present invention includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present invention belong.

[0173] It should be understood that the various parts of the present invention can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, a plurality of steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0174] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

[0175] In addition, each functional unit in each embodiment of the present invention may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0176] The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc.

[0177] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0178] Although the embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and are not to be construed as limitations of the present invention. A person skilled in the art may change, modify, replace and vary the above embodiments within the scope of the present invention.

Claims

1. A method for verifying consistency of structured data, characterized in that: include: The third-party trusted service Service calls the smart contract to obtain the random factor, and stores the random factor locally in the App application; Using the random factor, the App performs hash calculation on each field value of the newly added or updated data, and uses the hash value of each field value to calculate the Merkle tree root hash; The hash value of each field value and the Merkle tree root hash are stored in the blockchain in the form of logs through the third-party trusted service Service, and information and contract events are returned; wherein the returned information and contract events at least include: events, current block height and transaction flags; Calling the Web business service Service interface through the App application to write the data to be added or updated to the data storage device on the Web business service Service side; The data consumer or verifier obtains the user's data through the Web business Service and calls the third-party trusted service Service to verify the consistency of the data.

2. The method according to claim 1, characterized in that The method of obtaining the random factor by calling the smart contract through the third-party trusted service Service includes: Create a DID user identity; According to the DID user identity, query whether there is a random factor, and if so, return the random factor; If not, generate a random factor and encrypt the random factor using the user's public key to form a ciphertext; Persistently store the mapping relationship between ciphertext and DID mark and return the ciphertext.

3. The method according to claim 2, characterized in that The storing the random factor locally in the App application includes: The user enables the delegation mode of the App application and requests the third-party trusted service to keep the random factor.

4. The method according to claim 3, characterized in that The storing of the hash value of each field value and the Merkle tree root hash in the form of a log in the blockchain through the third-party trusted service Service includes: Monitor the smart contract BusinessContract event EventDataID; wherein the parameters of the event EventDataID include at least: hash array, number of hash array elements and block height; The solidifyEvidences interface of the smart contract BusinessContract is called, wherein the parameters of the interface solidifyEvidences include at least: a hash array and the number of elements in the hash array.

5. The method according to claim 4, characterized in that The returned information and contract events include: Parse the monitored EventDataID event, and store the event, block_height block height, transaction_index transaction index in the block, and log_index log index in the transaction persistently; The block_height block height in the event, the transaction_index transaction index in the block, and the log_index log index in the transaction are returned to the App application.

6. The method according to claim 5, characterized in that The App application calls the Web business service Service interface to write the data to be added or updated to the data storage device on the Web business service Service side, including: The request for the business interface needs to carry block_height, transaction_index and log_index; When data is persisted, the corresponding relationship between data and block_height, transaction_index, and log_index is saved.

7. The method according to claim 6, characterized in that The data consumer or verifier obtains the user's data through the Web business Service and calls the third-party trusted service Service to verify the consistency of the data, including: Determine whether the identity of the data consumer or verifier is consistent with that of the data creator; If they are consistent, a random factor is obtained from the App application; Using random factors to calculate the hash of each field value in the user's data obtained from the Web business service Service, and constructing a Merkle root hash of the user data according to the hash value; Call the blockchain SDK, obtain block information based on block_height, and use transaction_index and log_index to obtain EventDataID events; Parse the EventDataID event, obtain the Merkle tree root hash value, and compare it with the Merkle root hash value of the user data; If the values ​​are the same, the data of the Web business service Service has not been tampered with; Otherwise, the data has been tampered with, and by further comparing other elements in the hash array in the EventDataID event, the tampered field value can be confirmed.

8. The method according to claim 7, characterized in that If the identities of the data consumer or verifier are inconsistent with those of the data creator, the data consumer or verifier obtains the user's data through the Web business Service and calls the third-party trusted service Service to verify the consistency of the data, including: The third-party trusted service Service obtains through DID whether the data consumer or verifier has obtained the data authorization of the data creator; If authorization is not obtained, the third-party trusted service Service notifies the App application of the user authorization request; wherein the request parameters include at least: data consumer or verifier flag, data consumer or verifier public key, data consumer or verifier contact information and data usage purpose; After the authorization is passed, the third-party trusted service Service verifies the authorization information of the data consumer or verifier, and calls the third-party trusted service Service to verify the consistency of the data after the verification is passed.

9. The method according to claim 8, characterized in that The third-party trusted service Service notifies the App application of the user authorization request, including: The data consumer or verifier creates an authorization request, wherein the authorization request parameters include at least: a DID flag of the requester, a DID flag of the data source creator, data to be consumed or verified, and a request signature; The authorization request is sent to the App application, and the App application is notified of the user authorization request through the third-party trusted service Service.

10. The method according to claim 9, characterized in that The third-party trusted service Service verifies the authorization information of the data consumer or verifier, including: Get the DID from the authorization request src ; Using the DID src Get the corresponding DID document information from the blockchain; Get the DID from the DID document information src Authorization record information; Acquire the applicant's public key information from the authorization record information; Use the public key to verify the signature of the authorization request.

Images