Blockchain-based data storage insurance method, device, equipment and storage medium

Abstract

The application provides a blockchain-based data storage insurance method, device, equipment and storage medium, comprising: receiving target insurance data provided by a service party and service party data ledger, and customer party data ledger provided by a customer party. The data ledger contains the accounting entries corresponding to each updated version of the target insurance data, and the accounting entries record the summary information of the target insurance data corresponding to the updated version provided by the party and the summary information of the target insurance data corresponding to the updated version confirmed by the signature of the other party. The oracle of the blockchain is called to execute: matching the target insurance data on the service party side with the accounting entries in the data ledger of both parties. The insurance smart contract is called to execute: determining the insurance settlement list based on the matching result of the accounting entries, and submitting the blockchain transaction of executing the insurance settlement list to the blockchain. When the data stored by the service party on behalf of the customer party is damaged or missing, the service party can be constrained to perform the compensation obligation to the customer party.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a blockchain-based data storage insurance method, apparatus, device, and storage medium. Background Technology

[0002] Cloud storage is an online storage model. Cloud storage service providers prepare virtualized storage resources in the backend according to the client's needs and provide them to the client in the form of storage resource pools; correspondingly, the client can use the storage resource pools to store data online.

[0003] Currently, cloud storage and similar data storage services do not provide effective data protection mechanisms for their clients. If data entrusted to a client for storage is lost or damaged by the service provider, disputes often arise due to unclear compensation standards, and the client usually bears the loss themselves.

[0004] Therefore, it is necessary to develop a comprehensive data protection mechanism for data storage businesses to promote the healthy development of the ecosystem. Summary of the Invention

[0005] The purpose of this application is to provide a blockchain-based data storage insurance method, device, equipment, and storage medium that can provide security guarantees for customers' data storage services and effectively constrain the service provider to fulfill its compensation obligations to customers when the data stored by the service provider on behalf of the customer is damaged or lost.

[0006] To achieve the above objectives, the embodiments of this application are implemented as follows:

[0007] Firstly, a data storage insurance method based on blockchain is provided, applicable to any node device in the blockchain, wherein an insurance smart contract is deployed in the blockchain for setting up target insurance data, the target insurance data being stored by a service provider at the request of a customer, and the method is executed by any node device in the blockchain, including:

[0008] The system receives target insurance application data and the corresponding service provider data ledger provided by the service provider, as well as a customer data ledger containing the target insurance application data provided by the customer. The service provider data ledger and the customer data ledger contain accounting entries for the target insurance application data in each updated version. The first target accounting entry in each updated version of the service provider data ledger records a summary of the updated version to which the target insurance application data provided by the service provider belongs, and a summary of the updated version to which the target insurance application data belongs, confirmed by the customer's signature. The second target accounting entry in each updated version of the customer data ledger records a summary of the updated version to which the target insurance application data provided by the customer belongs, and a summary of the updated version to which the target insurance application data belongs, confirmed by the service provider's signature.

[0009] Call the oracle of the blockchain to perform the following: match the target insurance data provided by the service provider with the accounting entries in the service provider's data ledger and the customer's data ledger to obtain the matching results of the accounting entries;

[0010] The insurance smart contract is invoked to execute: an insurance settlement list is determined based on the matching results of the ledger entries, and a blockchain transaction for executing the insurance settlement list is submitted to the blockchain; wherein, the insurance settlement list includes premium resources paid by the customer to the service provider and / or claims resources paid by the service provider to the customer.

[0011] Secondly, a blockchain-based data storage insurance device is provided, applicable to any node device in the blockchain, wherein the blockchain is deployed with an insurance smart contract set for target insured data, and the device includes:

[0012] A receiving module is used to receive target insurance data and the corresponding service provider data ledger provided by a service provider, and a customer data ledger of the target insurance data provided by a customer; wherein, the service provider data ledger and the customer data ledger contain accounting entries corresponding to the target insurance data in each updated version; the first target accounting entry in each updated version of the service provider data ledger records summary information of the updated version to which the target insurance data provided by the service provider belongs, and summary information of the updated version to which the target insurance data belongs, confirmed by the customer's signature; the second target accounting entry in each updated version of the customer data ledger records summary information of the updated version to which the target insurance data provided by the customer belongs, and summary information of the updated version to which the target insurance data belongs, confirmed by the service provider's signature;

[0013] The matching module is used to call the oracle of the blockchain to perform the following: matching the target insurance data provided by the service provider with the accounting entries in the service provider's data ledger and the customer's data ledger to obtain the matching results of the accounting entries;

[0014] The settlement module is used to invoke the insurance smart contract to execute: determining an insurance settlement list based on the matching results of the accounting entries, and submitting a blockchain transaction to the blockchain to execute the insurance settlement list; wherein, the insurance settlement list includes premium resources paid by the customer to the service provider and / or claims resources paid by the service provider to the customer.

[0015] Thirdly, embodiments of this application provide an electronic device, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to perform the method described in the first aspect.

[0016] Fourthly, a computer-readable storage medium is provided for storing computer-executable instructions that, when executed by a processor, implement the method described in the first aspect.

[0017] Based on the solution proposed in this application, clients can insure the data they request to store and deploy the corresponding insurance smart contract on the blockchain. Simultaneously, both the client and the service provider maintain their own data ledgers to record the summary information of their provided insurance data for each updated version, as well as the summary information of the target insurance data signed and confirmed by the other party for each updated version. In other words, the summary information of the insurance data provided by both parties needs to be signed and confirmed before being shared with the other party. This mutual signature confirmation constraint prevents the summary information from being maliciously tampered with, ensuring that both parties' data ledgers can effectively prove the insurance data under each updated version. When insurance settlement is required, a decentralized oracle on the blockchain matches the client's and service provider's data ledgers with the target insurance data actually stored by the service provider, ensuring the objectivity of the matching result. The data ledgers of both the service provider and the client configure corresponding accounting entries to record summary information for each updated version of the insurance data. Through comparison, it can be found in which updated version the service provider failed to correctly store the client's insurance data. Subsequently, the insurance smart contract is invoked to determine the insurance settlement list based on the matching results provided by the oracle. For example, it determines the premium resources the client needs to pay to the service provider based on the correctly stored updated version, or the claim resources the service provider needs to pay to the client based on the incorrectly stored updated version. Therefore, it has clear compensation standards. It can be seen that the solution in this application provides an effective data protection mechanism for the client. When the data stored by the service provider on behalf of the client is damaged or missing, it can effectively constrain the service provider to fulfill its compensation obligations to the client. At the same time, it also supports the client in updating the insurance data, making it more practical. Attached Figure Description

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

[0019] Figure 1 This is a flowchart illustrating the data storage insurance method based on blockchain according to an embodiment of this application.

[0020] Figure 2 This is a schematic diagram of the data ledger for a blockchain-based data storage insurance method according to an embodiment of this application.

[0021] Figure 3 This is a schematic diagram of the architecture of the data storage insurance method based on blockchain according to an embodiment of this application.

[0022] Figure 4 This is a schematic diagram of the structure of a blockchain-based data storage insurance device according to an embodiment of this application.

[0023] Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

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

[0025] As mentioned earlier, current data storage services also lack effective data protection mechanisms for clients. Once data entrusted to a client for storage is lost or damaged by the service provider, disputes often arise due to unclear compensation standards, ultimately resulting in the client bearing the loss themselves. Especially during the use of data storage services, clients have reasonable needs to update the stored data, and the frequent changes to the stored data also create difficulties in providing evidence for claims.

[0026] Therefore, this application aims to provide a compensation mechanism for data storage based on blockchain technology, which can effectively bind the service provider to fulfill its compensation obligations to the customer when the data stored by the service provider on behalf of the customer is damaged or lost.

[0027] Specifically, in this application, the client can insure the data requested for storage and deploy the corresponding insurance smart contract on the blockchain. Simultaneously, both the client and the service provider maintain their own data ledgers to record the summary information of their provided insurance data for each updated version, as well as the summary information of the target insurance data signed and confirmed by the other party for each updated version. In other words, the summary information of the insurance data provided by both parties needs to be signed and confirmed before being shared with the other party. This mutual signature confirmation constraint prevents the summary information from being maliciously tampered with, ensuring that both parties' data ledgers can effectively prove the insurance data under each updated version. When insurance settlement is required, the blockchain's decentralized oracle matches the client's and service provider's data ledgers with the target insurance data actually stored by the service provider, ensuring the objectivity of the matching result. The service provider's and client's data ledgers are configured with corresponding accounting entries to record summary information for each updated version of the insurance data. Through comparison, it can be found in which updated version the service provider failed to correctly store the client's insurance data. Subsequently, the insurance smart contract is invoked to determine the insurance settlement list based on the matching results provided by the oracle. For example, it determines the premium resources the customer needs to pay to the service provider based on the correctly stored updated version, or the claim resources the service provider needs to pay to the customer based on the incorrectly stored updated version. Therefore, it has clear compensation standards. It can be seen that the solution in this application provides an effective data protection mechanism for the customer. When the data stored by the service provider on behalf of the customer is damaged or missing, it can effectively constrain the service provider to fulfill its compensation obligations to the customer. At the same time, it also supports the customer in updating the insurance data, making it more practical.

[0028] Based on the principles of the above-mentioned scheme, on the one hand, this application provides a blockchain-based data storage insurance method, which can be executed by any node device in the blockchain. The blockchain has deployed an insurance smart contract set up for the target insured data. The target insured data is a data object that the client requests the service provider to store, and the insurance smart contract contains the claims logic for the target insured data. The claims logic may be, but is not limited to, the claims resource price for the target insured data, which is pre-agreed between the client and the service provider based on the importance of the target insured data; this is not specifically limited here.

[0029] refer to Figure 1 , Figure 1 A flowchart illustrating the data storage insurance method provided in this application embodiment includes the following steps:

[0030] S102, receiving target insurance data and the corresponding service provider data ledger provided by the service provider, and customer data ledger of target insurance data provided by the customer; wherein, the service provider data ledger and the customer data ledger contain accounting entries corresponding to the target insurance data in each updated version; the first target accounting entry in each updated version in the service provider data ledger records summary information of the updated version to which the target insurance data provided by the service provider belongs and summary information of the updated version to which the target insurance data confirmed by the customer's signature belongs; the second target accounting entry in each updated version in the customer data ledger records summary information of the updated version to which the target insurance data provided by the customer belongs and summary information of the updated version to which the target insurance data confirmed by the service provider's signature belongs.

[0031] In this application, the target insurance data provided by the service provider is the latest version of the target insurance data currently stored by the service provider.

[0032] The customer's data ledger refers to the data ledger maintained by the customer for target insurance data. (Reference) Figure 2 As shown, each updated version of the target insurance data in the client's data ledger generates a record entry. Each record entry contains a summary of the updated version of the target insurance data provided by the client, as well as a summary of the updated version confirmed by the service provider's signature. For example: Record entry 1 in the client's data ledger contains a summary of the updated version 1 of the target insurance data provided by the client, as well as a summary of the updated version 1 of the target insurance data confirmed by the service provider's signature; Record entry 2 in the client's data ledger contains a summary of the updated version 2 of the target insurance data provided by the client, as well as a summary of the updated version 2 of the target insurance data confirmed by the service provider's signature; Record entry 3 in the client's data ledger contains a summary of the updated version 3 of the target insurance data provided by the client, as well as a summary of the updated version 3 of the target insurance data confirmed by the service provider's signature.

[0033] Similarly, the service provider's data ledger refers to the data ledger maintained by the service provider for the target insurance data. (Continue to refer to...) Figure 2As shown, each updated version of the target insurance data in the service provider's data ledger generates a record entry. Each record entry contains a summary of the updated version of the target insurance data provided by the service provider, as well as a summary of the updated version confirmed by the client's signature. For example: record entry 1 in the service provider's data ledger contains a summary of the updated version 1 of the target insurance data provided by the service provider and a summary of the updated version 1 of the target insurance data confirmed by the client's signature; record entry 2 in the service provider's data ledger contains a summary of the updated version 2 of the target insurance data provided by the service provider and a summary of the updated version 2 of the target insurance data confirmed by the client's signature; record entry 3 in the service provider's data ledger contains a summary of the updated version 3 of the target insurance data provided by the service provider and a summary of the updated version 3 of the target insurance data confirmed by the client's signature.

[0034] It should be understood that the digest information is generated by encrypting the target insurance application data (using common hash encryption algorithms such as MD5, SHA-1, and SHA-256). Once the target insurance application data changes, the corresponding digest information will also change; therefore, the digest information can also represent the content of the target insurance application data. For either the customer or the service provider, after providing the other party with the digest information of the target insurance application data that they have signed and confirmed, any subsequent tampering with the target insurance application data and / or the corresponding digest information will result in a mismatch with the information recorded in the other party's records. Therefore, this effectively curbs malicious behavior by both the customer and the service provider in tampering with the digest information.

[0035] It should be noted that the accounting entries in this application's data ledger are not limited to recording only the summary information of the updated version corresponding to the target insurance data.

[0036] As an example, the client pre-deposits premium guarantee resources with the insurance smart contract. Upon settlement, the insurance smart contract deducts the premium resources from the guarantee resources and pays the service provider's e-wallet. Correspondingly, refer to... Figure 2 As shown, the accounting entries in both parties' data ledgers can also record the theoretical balance of the premium guarantee resources in the corresponding updated version, as well as the theoretical balance of the premium guarantee resources in the corresponding updated version confirmed by the other party's signature. Here, the theoretical balance refers to the remaining balance of the premium guarantee resources after deducting the premiums payable, assuming the service provider correctly stores the target insurance data.

[0037] It should be understood that after the theoretical balance is recorded in the accounting entries, the data ledgers of both parties can also be reconciled based on the customer's theoretical premium payments. For either the customer or the service provider, if a data ledger with missing accounting entries is maliciously provided, it will result in a discrepancy between the customer's theoretical premium payments and the actual payments, thereby deterring the malicious act of adding or deleting accounting entries without authorization.

[0038] Here Figure 2 The data ledgers shown are for illustrative purposes only. Suppose the service provider arbitrarily deletes entry 3 from its own data equipment, causing discrepancies between the service provider's claims statement and the customer's data ledger. However, the customer's data ledger reveals that entry 3 records a theoretical balance confirmed by the service provider's signature for updated version 3. This indicates that the service provider initially acknowledged the target insurance data corresponding to updated version 3. Even if the service provider later deletes entry 3 from its own data ledger because the target insurance data corresponding to updated version 3 was not stored correctly, this cannot be concealed by the evidence of entry 3 in the customer's data ledger.

[0039] Furthermore, if the client and service provider agree to use an asymmetric algorithm for signature verification, either party can use its own non-temporary private key to generate a pair of temporary private and temporary public keys, and use the temporary private key for signature verification. Correspondingly, refer to... Figure 2 As shown, entries in either party's data ledger can also record the temporary private key used for signature verification and the corresponding temporary public key. Similarly, the oracle can use the client's temporary public key in the client's data ledger to parse the digest information and / or theoretical balance provided by the service provider, signed and verified by the client's private key; conversely, it can use the service provider's temporary public key in the service provider's data ledger to parse the digest information and / or theoretical balance provided by the client, signed and verified by the service provider's private key. It should be noted that private key signature verification is essentially encrypting information using a temporary private key. For the oracle to read the information after private key signature verification, it needs to use the matching temporary public key for parsing.

[0040] In practical applications, both the client and the service provider can configure dedicated temporary private keys for signing and confirming different updated versions of the target insurance data. For example... Figure 2 As shown, the client generates a temporary public-private key pair A1 for update version 1, and the service provider generates a temporary public-private key pair B1 for update version 1; the client generates a temporary public-private key pair A2 for update version 2, and the service provider generates a temporary public-private key pair B2 for update version 2; the client generates a temporary public-private key pair A3 for update version 3, and the service provider generates a temporary public-private key pair B3 for update version 3.

[0041] For either the customer or the service provider, whenever a new update is generated for the target insurance data, the temporary private key used for signing and confirming the previous update can be made public to the other party to indicate its invalidation. Correspondingly, the accounting entries in the service provider's data ledger and the customer's data ledger for non-initial update versions can also record the temporary private key used for signing and confirming the previous update. For example Figure 2 In the process, after the target insurance data is iterated to the updated version 2, the accounting entries in the customer's data ledger record the temporary private key B1 used by the service provider in the updated version 1, and the accounting entries in the service provider's data ledger record the temporary private key A1 used by the customer in the updated version 1; after the target insurance data is iterated to the updated version 3, the accounting entries in the customer's data ledger record the temporary private key B2 used by the service provider in the updated version 2, and the accounting entries in the service provider's data ledger record the temporary private key A2 used by the customer in the updated version 2.

[0042] It should be noted that if the service provider sets different update fees for different types of update operations (such as adding, modifying, and deleting) initiated by the client, please refer to [the relevant fee schedule]. Figure 2 As shown, the accounting entries in either party's data ledger can also record the corresponding update operation type or the update transaction fee that matches the update operation type. Figure 2 (Taking record update fees as an example). In this way, during settlement, the insurance smart contract can also calculate all update fee resources that the client needs to pay to the service provider based on the accounting entries in both parties' data ledgers. For the purposes of this application, update fee resources can also be included in the insurance settlement list.

[0043] Here Figure 2The data ledgers shown are for illustrative purposes only. Assume update version 1 is the initial update version of the target insurance data. Since the initial update version has no corresponding update operation, the update fee record 1 for entry 1 in both data ledgers is 0. Next, the client requests the service provider to add new data to the target insurance data. Assuming the service provider charges 0.5 digital tokens for the data addition update operation, after the data addition is completed, the update version of the target insurance data iterates from 1 to 2, and the corresponding data ledger generates entry 2, where the update fee 2 is recorded as 0.5 digital tokens. Then, the client requests the service provider to modify the target insurance data. Assuming the service provider charges 0.8 digital tokens for the data modification update operation, after the data modification is completed, the update version of the target insurance data iterates from 2 to 3, and the corresponding data ledger generates entry 3, where the update fee 3 is recorded as 0.8 digital tokens. For the insurance smart contract, simply summing all the update fees in each pair of entries is sufficient to determine the total update fee the client ultimately needs to pay.

[0044] Of course, if the service provider sets a uniform update fee for different types of update operations, the accounting entries in both parties' data ledgers no longer need to record the update fee. Instead, the fee rules are configured in the insurance smart contract, which directly calculates the total update fee the client needs to pay based on the number of update versions. For example, if the service provider charges 1 digital token for any type of update operation, and the target insured data corresponds to 8 update versions, excluding the initial update version, the actual number of update operations is 7, and the corresponding total update fee is 7 × 1 = 7 digital tokens.

[0045] S104, invoke the blockchain oracle to execute: match the target insurance data provided by the service provider with the accounting entries in the service provider's data ledger and the customer's data ledger to obtain the matching results of the accounting entries.

[0046] An oracle is essentially middleware for data access and retrieval, providing data from outside the blockchain to smart contracts within the blockchain for processing. Existing oracles can provide computation services, which are collaboratively performed by multiple nodes within the blockchain. Each node must determine its own computation result and broadcast it to other nodes for consensus. It is evident that oracle computation services offer the advantages of decentralization and objectivity. For this application, a computation service needs to be deployed within the oracle to match target insurance data provided by the service provider with entries in the service provider's and client's data ledgers. When matching is required, the oracle simply needs to be invoked to import the target insurance data provided by the service provider and the data ledgers of both parties to execute the computation service. Correspondingly, after determining the matching result of the entries, the oracle provides the matching result to the insurance smart contract, which then determines the insurance settlement list to complete the final settlement.

[0047] In the specific matching process, target summary information of the target insurance data provided by the service provider is first generated. Then, in order of update from newest to oldest, accounting entries in the service provider's data ledger and the customer's data ledger are selected and matched with the generated target summary information until a match is successful or all accounting entries in the updated versions fail to match. A successful match in any updated version means that, under that updated version, the summary information provided by the service provider recorded in the accounting entries in the service provider's data ledger and the summary information provided by the customer recorded in the accounting entries in the customer's data ledger are simultaneously consistent with the target summary information.

[0048] The following section explains the principle behind oracle matching.

[0049] As mentioned above, under the mutual signature constraint, neither party's data ledger can arbitrarily omit or add any updated accounting entries. Therefore, under normal circumstances, the updated versions recorded in the service provider's data ledger and the client's data ledger are consistent.

[0050] Here, we assume the updated versions are, from oldest to newest, version 1, 2, 3, and 4. Since the service provider offers the latest version of the target insurance data, the matching process begins by extracting the entry corresponding to update version 4 from both parties' data ledgers. Based on the summary information recorded in the update version 4 entries, this entry is matched against the target insurance data (target summary information) provided by the service provider. If the target insurance data does not match the summary information recorded in the update version 4 entries, the entry corresponding to update version 3 is extracted from both parties' data ledgers, and this entry is matched against the target insurance data provided by the service provider. If the target insurance data still does not match the summary information recorded in the update version 3 entries, the entry corresponding to update version 2 is extracted from both parties' data ledgers, and this entry is matched against the target insurance data provided by the service provider, based on the summary information recorded in the update version 2 entries. This process continues until a match is successful, or the target insurance data does not match the summary information recorded in the update version 1 entries.

[0051] If one party maliciously loses an updated version of the accounting entry, for example, if the service provider's data ledger is missing an accounting entry of version 4, then the accounting entry of version 4 will be directly defaulted to as failing to match.

[0052] Furthermore, if the target insurance data provided by the service provider matches the summary information recorded in one of the parties' accounting entries, the following two scenarios exist:

[0053] Scenario 1: The service provider provides maliciously altered summary information, meaning the service provider did not store the target insurance data correctly, but does not want to process the claim;

[0054] Scenario 2: The client provides maliciously altered summary information, meaning the service provider correctly stores the target insurance data, but the client attempts to commit insurance fraud.

[0055] Regardless of which of the above situations occurs, since both the service provider and the client have previously submitted the summary information after signing and confirming it to each other, even if it is maliciously altered later, it will not match the summary information that they previously signed and confirmed, and can be traced back in the future.

[0056] For the purposes of this application, after confirming the matching results of the ledger entries in each updated version, the oracle can send the matching results to both parties for confirmation. If one party does not accept the matching results, a third-party manual review can be initiated through the data ledgers of both parties. Under the constraint of mutual signatures on the data ledgers of both parties, the party committing the wrongdoing can be directly identified during the manual review. If both parties accept the matching results, the oracle will then further submit the matching results to the insurance smart contract.

[0057] Furthermore, after manual verification identifies the malicious party, the verdict can be submitted to an oracle via a blockchain node. The oracle then forwards this information to the insurance smart contract. The insurance smart contract is configured with penalty execution logic to punish the malicious party accordingly. For example, if a customer acts maliciously, the insurance smart contract can transfer all or part of the customer's previously pledged premium guarantee resources to the service provider's e-wallet via a blockchain transaction. Similarly, the service provider can pre-pledge claim guarantee resources to the insurance smart contract; if the service provider acts maliciously, the insurance smart contract can transfer all or part of the service provider's previously pledged claim guarantee resources to the customer's e-wallet via a blockchain transaction.

[0058] S106, Invoke the insurance smart contract to execute: Determine the insurance settlement list based on the matching results of the ledger entries, and submit the blockchain transaction for executing the insurance settlement list to the blockchain; wherein, the insurance settlement list includes the premium resources paid by the customer to the service provider and / or the claims resources paid by the service provider to the customer.

[0059] In this application, the insurance smart contract can set up independent premium resources and claims resources for each updated accounting entry, thereby enabling the settlement of premium resources and claims resources at the update version level.

[0060] As mentioned earlier, the oracle's computation service will select accounting entries from the service provider's data ledger and the client's data ledger in the order of newest to oldest and match them with the generated summary information until a match is successful or all accounting entries of the updated version fail to match.

[0061] As mentioned earlier, the oracle's computation service selects accounting entries from the service provider's data ledger and the client's data ledger in ascending order of update version and matches them with the generated summary information until a match is successful or all accounting entries of the updated version fail to match. In the embodiments of this application, the claims resources to be paid by the service provider to the client can be determined based on the accounting entries of the updated version that failed to match, and the premium resources to be paid by the client to the service provider can be determined based on the accounting entries of the updated version that successfully matched and the accounting entries of the updated version that did not match.

[0062] As an example, assume the update versions are, from oldest to newest, update version 1, 2, 3, 4, and 5. The oracle first extracts the summary information recorded in the accounting entries of update version 5 from both parties' data ledgers and matches it with the target insurance data. If the match fails, it then extracts the summary information recorded in the accounting entries of update version 4 from both parties' data ledgers and matches it with the target insurance data, and so on... Here, we further assume that the target insurance data provided by the service provider successfully matches the summary information recorded in the accounting entries corresponding to update version 3 in both parties' data ledgers. This indicates that the service provider correctly stored the target insurance data in update versions 1-3, but failed to correctly store the target insurance data starting from update version 4. In this case, the matching ends directly, and update versions 1 and 2 are update versions that were not matched. This application summarizes the premium resources corresponding to the accounting entries of updated versions 1-3 to determine all the premium resources that the customer ultimately needs to pay to the service provider. That is, the premium resources that the customer pays to the service provider are the sum of the premium resources corresponding to the successfully matched accounting entries of the updated version (updated version 3) and the accounting entries of the unmatched updated versions (updated versions 1 and 2). At the same time, the claims resources corresponding to the accounting entries of updated versions 4 and 5 are summarized to determine the claims resources that the service provider ultimately needs to pay to the customer. That is, the claims resources that the service provider pays to the customer are the sum of the claims resources corresponding to the accounting entries of the unmatched updated versions (updated versions 4 and 5).

[0063] Furthermore, if the service provider sets additional fees for the client's update operations, the insurance settlement list determined by the insurance smart contract may also include update fee resources that the client needs to pay to the service provider. Specifically, the update fee resources paid by the client to the service provider are the sum of the update fee resources corresponding to the successfully matched update version accounting entries and the unmatched update version accounting entries.

[0064] As an example, assume the update versions are, from oldest to newest, update version 1, 2, 3, 4, and 5. The service provider correctly stored the target insurance data in updates 1-3, but failed to store the target insurance data correctly starting with update version 4. Therefore, the update handling fee resources that the customer ultimately needs to pay the service provider should be the sum of the update handling fee resources corresponding to updates 1, 2, and 3. If the service provider does not charge update handling fee resources for the initial update version, then the update handling fee resources corresponding to update version 1 should be set to 0 by default.

[0065] In addition, the insurance smart contract is configured with penalty execution logic. If the oracle submits information about the wrongdoer, the insurance smart contract can impose corresponding penalties on the wrongdoer. This will not be elaborated on here.

[0066] The following describes the practical application of the data storage insurance method according to the embodiments of this application.

[0067] In this application, the service provider offers data storage services to the client. The client, using the data storage service application, applies to the service provider for a storage resource pool to store data online. Simultaneously, the client can initiate update operations on the stored data at any time through the service application. Furthermore, to demonstrate the trustworthiness of its data storage, the service provider offers data storage insurance to the client. If the client requires insurance, they can negotiate and establish data insurance rules with the service provider.

[0068] The data insurance rules include the following aspects:

[0069] 1) Premium cap and claims cap;

[0070] The premium cap refers to the premium guarantee resources that the customer needs to pledge in advance to the insurance smart contract, while the claim cap refers to the claim guarantee resources that the service provider needs to pledge in advance to the insurance smart contract. For example, if a user pledges a premium guarantee of 100 yuan at a time, the ratio of premium to claim will vary depending on the importance of the data; here, we assume it to be 1:10. In this case, the service provider would need to pledge a corresponding claim guarantee of 1,000 yuan in the insurance smart contract.

[0071] 2) Settlement cycle limit;

[0072] To prevent the service provider from not receiving premiums indefinitely, insurance requires periodic settlements. The reason for negotiating an upper limit for the settlement cycle, rather than a fixed cycle, is the possibility of early settlement. For example, if during the accounting process, it is discovered that the client's premium guarantee resources have run out of balance, and the settlement cycle has not yet arrived, early settlement is necessary.

[0073] 3) Determine the insured object;

[0074] Because stored data requires addition, deletion, and modification, the following methods can be used to determine the insured object:

[0075] Method 1 defines the entire target insurance data as an insurance object. For example, in a relational database, it can be a table, and in a non-relational database, it can be a collection. Set the premium according to the size of the data. In addition, set an update fee for update operations. Update operations can be adding, modifying, deleting, etc. The update fees for different update operations can be the same or different. There is no specific limitation here.

[0076] Method 2 defines the sub-data in the target insurance data as the insured object, sets a premium when creating it, and sets an update handling fee for update operations. Similarly, the update handling fees for different update operations can be the same or different.

[0077] After the insurance rules are negotiated, the service provider generates an insurance smart contract based on the rules and submits it to the client for signature confirmation. After the client's signature confirmation, the service provider deploys the insurance smart contract to the blockchain. The insurance smart contract enables the following:

[0078] 1) Insurance smart contracts can receive claims payments transferred from the service provider's digital wallet address, and the service provider can initiate active settlement requests to the insurance smart contracts.

[0079] 2) Insurance smart contracts can receive premiums transferred from the customer's digital wallet address, and the customer can initiate an active settlement request to the insurance smart contract.

[0080] 3) The insurance smart contract will automatically settle when the settlement period reaches its limit. For example, if the settlement limit period is one week, and no service provider initiates a settlement request or customer initiates a claim request within one week, the insurance smart contract will automatically settle.

[0081] After deploying insurance smart contracts on the blockchain, both the customer and the service provider record the target insurance data. This recording is done on a per-insured-object basis, and the recording process for a single insured-object is as follows:

[0082] 1) Initialize accounting data.

[0083] The initialization content includes:

[0084] (1) Summary information corresponding to the insured object; if there is no data for the current insured object, empty arrays such as "NULL" and "[]" can be regarded as the insured object to generate the corresponding summary information.

[0085] (2) The theoretical balance of premium guarantee resources;

[0086] (3) The temporary public key and temporary private key of the party (the client or the service provider); the temporary public key can be signed and authorized by the non-temporary private key of its own digital wallet. In other words, the temporary public key and temporary private key of the client (or the service provider) can prove that they originated from the client.

[0087] (4) Sign the two data items (1) and (2) using your temporary private key and submit them to the other party.

[0088] Specifically, any target update version of the accounting entry in the client's data ledger is generated when the client confirms that the following conditions are met:

[0089] The summary information of the target insurance data corresponding to the target updated version confirmed by the service provider's signature matches the target insurance data under the target updated version that this party requests to be stored by the service provider; and / or, the theoretical balance of the premium guarantee resources confirmed by the service provider under the target updated version matches the theoretical balance of the premium guarantee resources determined by this party under the target updated version.

[0090] In other words, for a specific target update version, after receiving the signed confirmation of data (1) and (2) from the service provider, the client needs to check whether the signed confirmation of data (1) and (2) from the service provider is consistent with the data (1) and (2) determined by the client. If they are consistent, the client will generate an accounting entry for that target update version in the client's data ledger. If they are inconsistent, the service provider is suspected of malicious activity, and the client can terminate the service and initiate an active settlement request.

[0091] Similarly, any target update entry in the service provider's data ledger is generated when the service provider confirms that the following conditions are met:

[0092] The summary information of the target insurance data confirmed by the service provider's signature in the target updated version matches the target insurance data stored by the service provider under the target updated version; and / or, the theoretical balance of the premium guarantee resources confirmed by the service provider under the target updated version matches the theoretical balance of the premium guarantee resources determined by the service provider under the target updated version.

[0093] In other words, for a specific target update version, after receiving the client's signed confirmation of data (1) and (2), the service provider needs to check whether the client's signed confirmation of data (1) and (2) is consistent with the data (1) and (2) determined by the service provider. If they are consistent, the service provider generates an accounting entry for that target update version in the service provider's data ledger. If they are inconsistent, the client is suspected of malicious activity, and the service provider can terminate the service and initiate an active settlement request.

[0094] 2) The customer initiates an update operation (add, modify, delete, etc.) on the target insurance data with the service provider, and begins the accounting process for the updated version of the target insurance data. The accounting process is as follows:

[0095] (1) Update the summary information of the insured object.

[0096] The insured object can refer to the entire target insurance data, or each sub-data in the target insurance data can be considered as an insured object on its own.

[0097] (2) The theoretical balance of premium guarantee resources;

[0098] The difference between the theoretical balance recorded by the customer in the previous transaction and the theoretical balance recorded in the current transaction is considered the customer's expenditure; the difference between the theoretical balance recorded by the service provider in the previous transaction and the theoretical balance recorded in the current transaction is considered the service provider's revenue.

[0099] (3) The temporary public key and temporary private key used by this party (the client or the service provider) in this update version;

[0100] The temporary public key and temporary private key used in this update are different from those used in the previous update.

[0101] refer to Figure 3 The architecture shown requires that, when settlement is needed, regardless of whether the initiator is a client or a service provider, or whether it's an automatic settlement, both the client and service provider must initiate an oracle call request to the blockchain node. The client's call request carries their data ledger, while the service provider's call request carries their data ledger and the target insurance data actually stored by the service provider. Correspondingly, upon receiving a call request from either party, the blockchain node inputs the provided data into the oracle, which then performs the computation service.

[0102] Specifically, the oracle in this application will automatically trigger the computation service according to the upper limit of the settlement cycle, or trigger the computation service after receiving a settlement request from one party. After the computation service is triggered, the oracle will start an internally set timer to keep track of the time.

[0103] If one party fails to submit the data ledger within the required time, the oracle will submit the result of the unsubmitted data ledger to the insurance smart contract, which will then process the settlement according to the requirements of the party that submitted the data ledger. For example, if the user submits the ledger and pays a premium of 10 yuan, and the insurance compensation ratio is 1:10, and the service provider fails to submit the ledger as required, the user can transfer the 10 yuan premium and the 100 yuan compensation to their digital wallet. Conversely, the service provider can transfer the 10 yuan premium to their digital wallet.

[0104] If both parties submit their data ledgers on time, the oracle's computation service generates summary information for each insured object based on the target insurance data submitted by the server, and matches the generated summary information with the summary information in both parties' data ledgers. As described above, the matching process proceeds in order of update version from newest to oldest, selecting accounting entries in the server's and client's data ledgers and matching them with the generated summary information until a match is successful or all updated accounting entries fail to match.

[0105] If the oracle successfully matches the insured item on the first attempt, it submits the result directly to the insurance smart contract. The smart contract calculates the total premium based on the premium resources corresponding to each insured item and deducts the corresponding amount from the premium guarantee resources previously pledged by the client, transferring the funds to the service provider's digital wallet. If the oracle fails to match successfully on the first attempt, it sends the result back to the blockchain node, which then notifies both the client and the service provider for confirmation. If both parties agree, the blockchain node invokes the oracle to submit the matching result to the insurance smart contract. The smart contract then determines the insurance settlement list, which, based on all the updated entries that failed to match, determines the claim resources the service provider needs to pay the client; and based on the updated entries that matched successfully and those that did not match, it determines the premium resources and update fees the client needs to pay the service provider.

[0106] Based on the above, it can be seen that the data storage security method of this application embodiment has the following characteristics:

[0107] 1) Subdivide the stored data into insured items and specify the compensation ratio for each item, and pre-determine the compensation for data loss or data tampering.

[0108] 2) Users can classify important and unimportant data themselves and pay different premiums for different data levels. In this way, the service provider is informed which data is more important to the customer and requires stronger management of security and integrity.

[0109] 3) The basis for insurance settlement is determined through the computing service of oracles, and the blockchain transaction for insurance settlement is completed by smart contracts. In other words, the determination of premiums and claims is completed by the blockchain, not the service provider. Even if the customer does not trust the service provider, the blockchain is absolutely decentralized.

[0110] 4) Insurance smart contracts are settled periodically. Each period processes a batch of update operations corresponding to the data ledger, so that insurance smart contracts will not be frequently invoked due to the rapid changes in the insured object.

[0111] 5) By using digital wallet signatures and temporary public and private key signatures, a data accounting process trusted by both parties is maintained, without the need for a third party to witness the transaction, making the accounting process highly efficient.

[0112] With the above Figure 1 Corresponding to the method shown, this application embodiment also provides a blockchain-based data storage insurance device. Figure 4 This is a schematic diagram of the data storage and security device 400 according to an embodiment of this application, including:

[0113] The receiving module 410 is used to receive target insurance data and the corresponding service provider data ledger provided by the service provider, and customer data ledger of the target insurance data provided by the customer; wherein, the service provider data ledger and the customer data ledger contain accounting entries corresponding to the target insurance data in each updated version; the first target accounting entry in each updated version of the service provider data ledger records summary information of the updated version to which the target insurance data provided by the service provider belongs and summary information of the updated version to which the target insurance data belongs, confirmed by the customer's signature; the second target accounting entry in each updated version of the customer data ledger records summary information of the updated version to which the target insurance data provided by the customer belongs and summary information of the updated version to which the target insurance data belongs, confirmed by the service provider's signature.

[0114] The matching module 420 is used to call the oracle of the blockchain to perform the following: matching the target insurance data provided by the service provider with the accounting entries in the service provider's data ledger and the customer's data ledger to obtain the matching result of the accounting entries.

[0115] The settlement module 430 is used to call the insurance smart contract to execute: determining an insurance settlement list based on the matching results of the accounting entries, and submitting a blockchain transaction to the blockchain to execute the insurance settlement list; wherein, the insurance settlement list includes the premium resources paid by the customer to the service provider and / or the claims resources paid by the service provider to the customer.

[0116] Based on the device described in this application, a client can insure the data requested for storage and deploy the corresponding insurance smart contract on the blockchain. Simultaneously, both the client and the service provider maintain their own data ledgers to record the summary information of their provided insurance data for each updated version, as well as the summary information of the target insurance data signed and confirmed by the other party for each updated version. In other words, the summary information of the insurance data provided by both parties needs to be signed and confirmed before being shared with the other party. This mutual signature confirmation constraint prevents the summary information from being maliciously tampered with, ensuring that both parties' data ledgers can effectively prove the insurance data under each updated version. When insurance settlement is required, a decentralized oracle on the blockchain matches the client's and service provider's data ledgers with the target insurance data actually stored by the service provider, ensuring the objectivity of the matching result. The data ledgers of both the service provider and the client configure corresponding accounting entries to record summary information for each updated version of the insurance data. Through comparison, it can be found in which updated version the service provider failed to correctly store the client's insurance data. Subsequently, the insurance smart contract is invoked to determine the insurance settlement list based on the matching results provided by the oracle. For example, it determines the premium resources the customer needs to pay to the service provider based on the correctly stored updated version, or the claim resources the service provider needs to pay to the customer based on the incorrectly stored updated version. Therefore, it has clear compensation standards. It can be seen that the solution in this application provides an effective data protection mechanism for the customer. When the data stored by the service provider on behalf of the customer is damaged or missing, it can effectively constrain the service provider to fulfill its compensation obligations to the customer. At the same time, it also supports the customer in updating the insurance data, making it more practical.

[0117] Optionally, the matching module 420 matches the target insurance data provided by the service provider with the accounting entries in the service provider's data ledger and the customer's data ledger, including:

[0118] Generate target summary information for the target insurance data provided by the service provider;

[0119] Following the order of updated versions from newest to oldest, accounting entries in the service provider's data ledger and the customer's data ledger are sequentially selected and matched with the target summary information until a match is found. A successful match in any updated version means that, under that updated version, the summary information provided by the service provider recorded in the accounting entries of the service provider's data ledger and the summary information provided by the customer recorded in the accounting entries of the customer's data ledger simultaneously match the target summary information; or...

[0120] In order of update from newest to oldest, accounting entries are selected from the service provider's data ledger and the customer's data ledger and matched with the target summary information in turn, until a match fails. A match failure means that the target summary information fails to match any accounting entry in all updated versions.

[0121] Optionally, the insurance smart contract sets independent premium resources and claims resources for each updated version of the accounting entry; the settlement module 430 determines the insurance settlement list based on the matching results of the accounting entries, including: determining the claims resources to be paid by the service provider to the customer based on the accounting entries of the updated versions that failed to match, wherein the claims resources to be paid by the service provider to the customer are the sum of the claims resources corresponding to the accounting entries of the updated versions that failed to match; and / or, determining the premium resources to be paid by the customer to the service provider based on the accounting entries of the updated versions that successfully matched and the accounting entries of the updated versions that did not match, wherein the updated versions that did not match refer to the updated versions before the updated versions that successfully matched.

[0122] The insurance smart contract sets an independent update fee for each updated accounting entry; the settlement module 430 determines the insurance settlement list based on the matching results of the accounting entries, including: determining the premium resources to be paid by the customer to the service provider based on the successfully matched updated accounting entries and the unmatched updated accounting entries.

[0123] Optionally, the accounting entries in the service provider's data ledger and the customer's data ledger also record the update fee resources corresponding to the updated version; the settlement module 430 determines the insurance settlement list based on the matching results of the accounting entries, and further includes: summarizing the update fee resources of the successfully matched updated version accounting entries and the unmatched updated version accounting entries, and determining the update fee resources paid by the customer to the service provider.

[0124] Optionally, the client has pre-deposited premium guarantee resources with the insurance smart contract, and the premium resources paid by the client to the service provider are deducted from the deposited premium guarantee resources; the accounting entries in the service provider's data ledger and the client's data ledger also record the theoretical balance of the premium guarantee resources provided by the client in the corresponding updated version and the theoretical balance of the premium guarantee resources confirmed by the other party's signature in the corresponding updated version.

[0125] Optionally, the accounting entries in the service provider's data ledger and the customer's data ledger also record a temporary private key used by the service provider for signature confirmation and a temporary public key corresponding to the temporary private key, wherein the temporary private key and temporary public key used by the service provider for signature confirmation are generated based on the service provider's non-temporary private key.

[0126] Optionally, any target update version of the accounting entry in the client's data ledger is generated when the client confirms that the following conditions are met:

[0127] The summary information of the target insurance data corresponding to the target updated version confirmed by the service provider's signature matches the target insurance data under the target updated version requested by this party from the service provider; and / or, the theoretical balance of the premium guarantee resource under the target updated version confirmed by the service provider's signature matches the theoretical balance of the premium guarantee resource under the target updated version determined by this party.

[0128] Optionally, any accounting entry in the service provider's data ledger for a target updated version is generated when the service provider confirms that the following conditions are met:

[0129] The summary information of the target insurance data corresponding to the target updated version confirmed by the service provider's signature matches the target insurance data under the target updated version stored by the party; and / or, the theoretical balance of the premium guarantee resource corresponding to the target updated version confirmed by the service provider's signature matches the theoretical balance of the premium guarantee resource corresponding to the target updated version determined by the party.

[0130] Optionally, the client and the service provider each configure a unique temporary private key for signing and confirming the target insurance data for different updated versions. After generating a new updated version of the target insurance data, the client discloses the temporary private key used for signing and confirming the previous updated version to the other party to indicate that it is invalid. The accounting entries in the service provider's data ledger and the client's data ledger for non-initial updated versions also record the temporary private key used for signing and confirming the other party in the previous updated version.

[0131] Obviously, Figure 4 The device shown can be used as Figure 1 The execution body of the method shown can therefore be implemented in... Figure 1 The steps and corresponding functions are shown below. Since the principles are the same, they will not be described in detail here.

[0132] In addition, this application also provides an electronic device. Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Please refer to it. Figure 5At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for other business operations.

[0133] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0134] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0135] Specifically, the processor reads the corresponding computer program from non-volatile memory into memory and then runs it, forming the above-mentioned logical structure. Figure 5 The data storage and security device shown. Correspondingly, the processor executes the program stored in the memory, and specifically performs the following operations:

[0136] The system receives target insurance application data and the corresponding service provider data ledger provided by the service provider, as well as a customer data ledger containing the target insurance application data provided by the customer. The service provider data ledger and the customer data ledger contain accounting entries for the target insurance application data in each updated version. The first target accounting entry in each updated version of the service provider data ledger records a summary of the updated version to which the target insurance application data provided by the service provider belongs, along with a summary of the updated version to which the target insurance application data belongs, confirmed by the customer's signature. The second target accounting entry in each updated version of the customer data ledger records a summary of the updated version to which the target insurance application data provided by the customer belongs, along with a summary of the updated version to which the target insurance application data belongs, confirmed by the service provider's signature.

[0137] The oracle of the blockchain is invoked to perform the following: matching the target insurance data provided by the service provider with the accounting entries in the service provider's data ledger and the customer's data ledger to obtain the matching results of the accounting entries.

[0138] The insurance smart contract is invoked to execute: an insurance settlement list is determined based on the matching results of the ledger entries, and a blockchain transaction for executing the insurance settlement list is submitted to the blockchain; wherein, the insurance settlement list includes premium resources paid by the customer to the service provider and / or claims resources paid by the service provider to the customer.

[0139] Based on the electronic device described in this application, the client can insure the requested data and deploy the corresponding insurance smart contract on the blockchain. Simultaneously, both the client and the service provider must maintain their respective data ledgers to record the summary information of their provided insurance data for each updated version, as well as the summary information of the target insurance data signed and confirmed by the other party for each updated version. In other words, the summary information of the insurance data provided by both parties needs to be signed and confirmed before being shared with the other party. This mutual signature confirmation constraint prevents the summary information from being maliciously tampered with, ensuring that both parties' data ledgers can effectively prove the insurance data under each updated version. When insurance settlement is required, the blockchain's decentralized oracle matches the client's and service provider's data ledgers with the target insurance data actually stored by the service provider, ensuring the objectivity of the matching result. The service provider's and client's data ledgers will configure corresponding accounting entries to record summary information for each updated version of the insurance data. Through comparison, it can be found in which updated version the service provider failed to correctly store the client's insurance data. Subsequently, the insurance smart contract is invoked to determine the insurance settlement list based on the matching results provided by the oracle. For example, it determines the premium resources the client needs to pay to the service provider based on the correctly stored updated version, or the claim resources the service provider needs to pay to the client based on the incorrectly stored updated version. Therefore, it has clear compensation standards. It can be seen that the solution in this application provides an effective data protection mechanism for the client. When the data stored by the service provider on behalf of the client is damaged or missing, it can effectively constrain the service provider to fulfill its compensation obligations to the client. At the same time, it also supports the client in updating the insurance data, making it more practical.

[0140] The data storage security method disclosed in the embodiments shown above can be applied to a processor and implemented by the processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0141] Of course, in addition to software implementation, the electronic device described in this specification does not exclude other implementation methods, such as logic devices or a combination of hardware and software. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0142] Furthermore, embodiments of this application also propose a computer-readable storage medium that stores one or more programs, the one or more programs including instructions.

[0143] Optionally, when the above instructions are executed by a portable electronic device that includes multiple applications, the portable electronic device can perform... Figure 1 The steps of the method shown include:

[0144] The system receives target insurance application data and the corresponding service provider data ledger provided by the service provider, as well as a customer data ledger containing the target insurance application data provided by the customer. The service provider data ledger and the customer data ledger contain accounting entries for the target insurance application data in each updated version. The first target accounting entry in each updated version of the service provider data ledger records a summary of the updated version to which the target insurance application data provided by the service provider belongs, along with a summary of the updated version to which the target insurance application data belongs, confirmed by the customer's signature. The second target accounting entry in each updated version of the customer data ledger records a summary of the updated version to which the target insurance application data provided by the customer belongs, along with a summary of the updated version to which the target insurance application data belongs, confirmed by the service provider's signature.

[0145] The oracle of the blockchain is invoked to perform the following: matching the target insurance data provided by the service provider with the accounting entries in the service provider's data ledger and the customer's data ledger to obtain the matching results of the accounting entries.

[0146] The insurance smart contract is invoked to execute: an insurance settlement list is determined based on the matching results of the ledger entries, and a blockchain transaction for executing the insurance settlement list is submitted to the blockchain; wherein, the insurance settlement list includes premium resources paid by the customer to the service provider and / or claims resources paid by the service provider to the customer.

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

[0148] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0149] The above are merely embodiments of this specification and are not intended to limit the scope of this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification. Furthermore, all other embodiments obtained by those skilled in the art without inventive effort should fall within the protection scope of this document.

Claims

1. A blockchain-based data storage insurance method, characterized in that, The application is applied to any node device in a blockchain, wherein the blockchain is deployed with an insurance smart contract set for target insurance data requested by a client to be stored by a service provider, and the target insurance data comprises: receiving target insurance data and corresponding service provider data ledger provided by the service provider, and client data ledger of the target insurance data provided by the client; wherein the service provider data ledger and the client data ledger contain accounting entries corresponding to each updated version of the target insurance data; the first target accounting entry of each updated version in the service provider data ledger records the digest information of the updated version to which the target insurance data provided by the service provider belongs and the digest information of the updated version to which the target insurance data provided by the client is signed and confirmed; the second target accounting entry of each updated version in the client data ledger records the digest information of the updated version to which the target insurance data provided by the client belongs and the digest information of the updated version to which the target insurance data corresponding to the service provider is signed and confirmed; calling an oracle of the blockchain to perform: matching the target insurance data provided by the service provider with the accounting entries in the service provider data ledger and the client data ledger to obtain a matching result of the accounting entries; calling the insurance smart contract to perform: determining an insurance settlement list based on the matching result of the accounting entries, and submitting a blockchain transaction for executing the insurance settlement list to the blockchain; wherein the insurance settlement list comprises premium resources paid by the client to the service provider and / or claim settlement resources paid by the service provider to the client.

2. The method of claim 1, wherein, The calling of the oracle of the blockchain to perform: matching the target insurance data provided by the service provider with the accounting entries in the service provider data ledger and the client data ledger comprises: generating target digest information of the target insurance data provided by the service provider; sequentially selecting accounting entries in the service provider data ledger and the client data ledger in the order from new to old according to the updated version, and matching the target digest information, until a match is successful, wherein any updated version match success means that the digest information provided by the service provider recorded in the accounting entry in the service provider data ledger and the digest information provided by the client recorded in the accounting entry in the client data ledger are consistent with the target digest information at the same time; or sequentially selecting accounting entries in the service provider data ledger and the client data ledger in the order from new to old according to the updated version, and matching the target digest information, until a match fails, wherein the match failure means that the target digest information fails to match all the accounting entries of the updated version.

3. The method of claim 2, wherein, The insurance smart contract sets independent premium resources and claim settlement resources for each accounting entry of the updated version; the calling of the insurance smart contract to perform: determining an insurance settlement list based on the matching result of the accounting entries comprises: determining, based on the matched updated version of the accounting entry, a claim settlement resource paid by the service party to the customer party, wherein the claim settlement resource paid by the service party to the customer party is a sum of claim settlement resources corresponding to the matched updated version of the accounting entry; and / or determining, based on the matched updated version of the accounting entry and the un-matched updated version of the accounting entry, a premium resource paid by the customer party to the service party, wherein the premium resource paid by the customer party to the service party is a sum of premium resources corresponding to the matched updated version of the accounting entry and the un-matched updated version of the accounting entry, wherein the un-matched updated version refers to an updated version before the matched updated version.

4. The method of claim 2, wherein the accounting entry in the service party data ledger and the customer party data ledger further records an updated commission resource corresponding to the belonging updated version; determining, based on the matching result of the accounting entry, an insurance settlement list further comprises: determining, based on the matched updated version of the accounting entry and the un-matched updated version of the accounting entry, an updated commission resource paid by the customer party to the service party, wherein the updated commission resource paid by the customer party to the service party is a sum of updated commission resources corresponding to the matched updated version of the accounting entry and the un-matched updated version of the accounting entry, wherein the un-matched updated version refers to an updated version before the matched updated version.

5. The method of claim 2, wherein, the customer party pre-mortgages a premium guarantee resource to the insurance smart contract, and the premium resource paid by the customer party to the service party is deducted from the mortgaged premium guarantee resource; the accounting entry in the service party data ledger and the customer party data ledger further records a theoretical balance of the premium guarantee resource provided by the party under the belonging updated version and a theoretical balance of the premium guarantee resource signed and confirmed by the opposite party under the belonging updated version.

6. The method of claim 5, wherein, the accounting entry of any target updated version in the customer party data ledger is generated when the customer party confirms that the following conditions are met: the target premium data signed and confirmed by the service party corresponds to the digest information of the target updated version, and the target premium data under the target updated version requested to be stored by the customer party to the service party matches; and / or the theoretical balance of the premium guarantee resource under the target updated version signed and confirmed by the service party matches the theoretical balance of the premium guarantee resource under the target updated version determined by the customer party; the accounting entry of any target updated version in the service party data ledger is generated when the service party confirms that the following conditions are met: The service-side signature-confirmed target insurance data corresponds to the digest information of the target update version, and matches the target insurance data under the target update version stored by the client side; and / or the service-side signature-confirmed premium guarantee resource under the target update version matches the corresponding theoretical balance of the premium guarantee resource under the target update version determined by the client side.

7. The method of claim 6, wherein, The client side and the service side are configured with exclusive temporary private keys for signature confirmation for the target insurance data of different update versions, and one of the client side and the service side discloses the temporary private key for signature confirmation of the last update version to the other party to indicate invalidation after generating the target insurance data of a new update version. The accounting entry of the non-initial update version in the service-side data ledger further records the temporary private key for signature confirmation of the last update version of the client side; and the accounting entry of the non-initial update version in the client-side data ledger further records the temporary private key for signature confirmation of the last update version of the service side. 8.A blockchain-based data storage insurance apparatus, characterized by, The device is applied to any node device in a blockchain, and the blockchain is deployed with an insurance smart contract set for target insurance data, and the device comprises: A receiving module is configured to receive target insurance data and a corresponding service-side data ledger provided by a service side, and a client-side data ledger of the target insurance data provided by a client side; wherein the service-side data ledger and the client-side data ledger contain accounting entries corresponding to each update version of the target insurance data; a first target accounting entry of each update version in the service-side data ledger records digest information of an update version to which the target insurance data provided by the service side belongs and digest information of an update version to which the target insurance data signed and confirmed by the client side belongs; and a second target accounting entry of each update version in the client-side data ledger records digest information of an update version to which the target insurance data provided by the client side belongs and digest information of an update version to which the target insurance data signed and confirmed by the service side belongs; A matching module is configured to call an oracle of the blockchain to perform: matching the target insurance data provided by the service side with the accounting entries in the service-side data ledger and the client-side data ledger to obtain a matching result of the accounting entries; A settlement module is configured to call the insurance smart contract to perform: determining an insurance settlement list based on the matching result of the accounting entries, and submitting a blockchain transaction for executing the insurance settlement list to the blockchain; wherein the insurance settlement list includes premium resources paid by the client side to the service side and / or claim settlement resources paid by the service side to the client side.

9. An electronic device, comprising: The device comprises: A processor; and a memory configured to store computer-executable instructions that, when executed, cause the processor to perform the method of any one of claims 1-7. The device comprises: A processor; and a memory configured to store computer-executable instructions that, when executed, cause the processor to perform the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium is configured to store computer executable instructions which, when executed by the processor, implement the method of any one of claims 1-7.

Images