CN111417945A

CN111417945A - Credible insurance letter based on block chain

Info

Publication number: CN111417945A
Application number: CN202080000556.4A
Authority: CN
Inventors: 陆旭明; 周徽; 叶国俊
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-02-03
Filing date: 2020-02-03
Publication date: 2020-07-14
Anticipated expiration: 2040-02-03
Also published as: WO2020098833A3; CN111417945B; US20220058639A1; WO2020098833A2; SG11202013136SA; EP3799643A4; EP3799643B1; EP3799643A2; WO2020098833A9; US11138602B2; US20210150515A1; US11580539B2

Abstract

Methods, systems, and apparatus, including computer programs encoded on a computer storage medium, for processing blockchain-based insurance information are disclosed. One of the methods comprises the following steps: receiving a first ciphertext of a first digital document specifying a insurance from a first computing device associated with at least a first guarantor, the first digital document specifying one or more predetermined conditions for performing the insurance, and one or more Zero Knowledge Proofs (ZKPs) associated with one or more values associated with the insurance; verifying that one or more zero knowledge proofs are correct; after verifying that the one or more zero knowledge proofs are correct, storing the first ciphertext into a blockchain based on performing a consensus algorithm; receiving a first message from a second computing device associated with the beneficiary or representative of the beneficiary, the first message comprising a request to modify the insurance; sending a second message to the first computing device relating to the request to modify the insurance policy; a second ciphertext of a second digital document specifying a insurance envelope is received from the first computing device, the second digital document representing a modified version of the first digital document, wherein the modification is based on the request.

Description

Credible insurance letter based on block chain

Technical Field

This document relates to providing trusted insurance based on blockchain techniques.

Background

The distributed ledger system (D L S), which may also be referred to as a consensus network and/or blockchain network, enables participating entities to securely and non-tamperproof store data.

Digital networks have enabled people around the world to conveniently and efficiently find and interact with information. For example, social media platforms allow people to easily share messages, photos, and videos with friends and colleagues. Online shopping websites allow consumers to easily find information about various products and send payments electronically to purchase products from businesses around the world. News websites provide users with up-to-date information about events occurring around the world. The media platform provides a user with a large amount of music and movies for the user to download or stream online. The user can use various financial services online and can more easily conduct international transactions. The taxi calling platform enables the lift to easily find the vehicle by using the mobile phone and pay for the vehicle. As more and more people use the internet and more transactions are conducted digitally, the number of fraudulent online activities and disputes between parties has increased.

Conventional secure messaging networks (e.g., SWIFT) typically support point-to-point messaging. The syntax of such messages is designed specifically for the two parties involved to ensure data security and privacy. However, due to different international technical or financial regulations, messages may pass through multiple nodes before reaching the final destination, which makes them time consuming, expensive and lacking in transparency. When more than two parties are involved, the message routing efficiency between the parties becomes even less under a point-to-point infrastructure.

A unified platform that can provide transparent, immutable, and verifiable messaging records while ensuring data privacy for the parties involved is desired.

Disclosure of Invention

Embodiments of the described subject matter may include one or more features, either alone or in combination.

For example, in one embodiment, a computer-implemented method performed by a computing system associated with at least one guarantor for processing insurance information to be stored on a blockchain, the method comprising: receiving, from a computing device associated with an applicant, an application for an insurance from at least a first insurer to a beneficiary, wherein the application includes information associated with the identity of the applicant, the identity of the beneficiary, and one or more predetermined conditions under which the insurance is performed; generating a digital version of the insurance based on information included in the application; encrypting the digital version to generate a ciphertext of the insurance; generating one or more Zero Knowledge Proofs (ZKPs) relating to one or more values associated with the insurance function; and sending the ciphertext of the insurance function and the one or more zero knowledge proofs to the blockchain network to store the ciphertext of the insurance function on the blockchain, wherein the ciphertext of the insurance function is stored on the blockchain through consensus of the blockchain nodes after the one or more zero knowledge proofs are successfully verified by the blockchain nodes in the blockchain network.

In another embodiment, a computer-implemented method performed by a block link point in a block chain network comprises: receiving ciphertext of a digital document specifying an insurance policy from a first computing device associated with a first guarantor, and one or more zero knowledge proofs relating to one or more values associated with the insurance policy, wherein the insurance policy is made by the first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions for executing the insurance policy; verifying that one or more zero knowledge proofs are correct; after verifying that the one or more zero knowledge proofs are correct, storing the ciphertext into a blockchain based on performing a consensus algorithm; receiving a first message from a second computing device associated with the beneficiary or a representative of the beneficiary, the first message including the beneficiary's acceptance of the insurance; and updating the status of the insurance policy to indicate that the beneficiary has accepted the insurance policy.

In another embodiment, a computer-implemented method performed by a block link point in a block chain network comprises: receiving a ciphertext of a digital document specifying an insurance, and one or more zero-knowledge proofs relating to one or more values associated with the insurance, wherein the insurance is made by at least a first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions under which the insurance is to be performed; verifying one or more zero knowledge proofs; after successful verification of one or more zero knowledge proofs, storing the ciphertext into a blockchain based on executing a consensus algorithm; receiving a withdrawal request for the insurance from a first computing device associated with the beneficiary or a representative of the beneficiary; storing the withdrawal request into a blockchain based on executing a consensus algorithm; communicating a first message regarding the withdrawal request to a second computing device associated with the first guarantor; receiving a second message from a second computing device associated with the first guarantor, the second message indicating that the first guarantor agrees to pay the beneficiary in accordance with the insurance policy; updating the status of the deposit letter stored in the blockchain to indicate that the first guarantor has processed the withdrawal request for the deposit letter; communicating a third message to the first computing device associated with the beneficiary or representative of the beneficiary, the third message indicating that the first guarantor agrees to pay the beneficiary in accordance with the insurance policy; receiving a fourth message from the first computing device associated with the beneficiary or a representative of the beneficiary, the fourth message indicating that the beneficiary has received payment from the first guarantor; and updating the status of the insurance policy stored in the blockchain to indicate that the beneficiary has received payment for the insurance policy.

In another embodiment, a computer-implemented method performed by a block link point in a block chain network comprises: receiving a ciphertext of a digital document specifying a guarantee and one or more zero knowledge proofs relating to one or more values associated with the guarantee, wherein the guarantee is made by at least a first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions under which the guarantee is performed; verifying one or more zero knowledge proofs; after successful verification of one or more zero knowledge proofs, storing the ciphertext into a blockchain based on executing a consensus algorithm; receiving a first message from a first computing device associated with the beneficiary or a representative of the beneficiary, the first message indicating that there are no unpaid claims for the insurance premium; sending a second message to a second computing device associated with the first guarantor to confirm that the first guarantor is disbursed from payment obligations under the insurance premium; receiving a third message from a second computing device associated with the first guarantor, the third message requesting that the status of the insurance policy be changed to expired; and updating a state of the insurance policy stored in the blockchain to indicate that the insurance policy has expired.

In another embodiment, a computer-implemented method performed by a block link point in a block chain network comprises: receiving a first ciphertext of a first digital document specifying an insurance from a first computing device associated with at least a first guarantor, and one or more zero knowledge proofs relating to one or more values associated with the insurance, wherein the insurance is made by the at least first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions for executing the insurance; verifying that one or more zero knowledge proofs are correct; after verifying that the one or more zero knowledge proofs are correct, storing the first ciphertext into a blockchain based on performing a consensus algorithm; receiving a first message from a second computing device associated with the beneficiary or representative of the beneficiary, the first message comprising a request to modify the insurance; sending a second message to the first computing device relating to the request to modify the insurance policy; and receiving, from the first computing device, a second ciphertext of a second digital document specifying a insurance policy, the second digital document representing a modified version of the first digital document, wherein the modification is based on the request.

In another embodiment, a computer-implemented method performed by a block link point in a block chain network comprises: receiving ciphertext of a digital document specifying an insurance policy from a first computing device associated with at least a first guarantor, and one or more zero knowledge proofs relating to one or more values associated with the insurance policy, wherein the insurance policy is made by the at least first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions for executing the insurance policy; verifying that one or more zero knowledge proofs are correct; after verifying that the one or more zero knowledge proofs are correct, storing the first ciphertext into a blockchain based on performing a consensus algorithm; receiving a first message from a first computing device associated with at least a first guarantor, the first message comprising a request to revoke a insurance policy; storing a request to revoke a guarantee in a blockchain; sending a second message to a second computing device associated with the beneficiary or representative of the beneficiary, wherein the second message comprises a request to revoke the insurance policy; receiving a third message from a second computing device associated with the beneficiary or representative of the beneficiary, wherein the third message comprises confirmation of acceptance of the revocation insurance policy by the beneficiary; and updating the status of the insurance policy stored in the blockchain to indicate that the insurance policy has been revoked.

In another embodiment, a computer-implemented method performed by a block link point in a block chain network comprises: a blockchain node in the first blockchain network receives a cross-chaining request for relaying a ciphertext of a digital document to the second blockchain network, wherein the cross-chaining request is sent from a first computing device associated with a first guarantor, the digital document specifies an insurance from the first guarantor and one or more predetermined conditions for performing the insurance, and the insurance is made by the first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions for performing the insurance; storing the cross-chain request and the ciphertext into a first blockchain associated with a first blockchain network based on executing a consensus algorithm; receiving, from the second computing device, a message for relaying information between the first blockchain network and the second blockchain network, the message including an acknowledgement that the insurance policy was accepted by the beneficiary and stored on a second blockchain associated with the second blockchain network; and updating the state of the insurance policy to indicate that the insurance policy has been invalidated on the first blockchain.

In some embodiments, these general and specific aspects may be implemented using a system, method, or computer program, or any combination of systems, methods, and computer programs. The foregoing and other described embodiments may each optionally include one or more of the following aspects:

in some embodiments, the insurance is in the form of a reserve letter of credit (SB L C). in some embodiments, the insurance specifies that the insurer should pay a predetermined amount to the beneficiary when one or more predetermined conditions for executing the insurance are met.

In some embodiments, the guarantor is an offshore bank that provides services to the applicant and the predetermined amount is paid to the beneficiary through an onshore bank that provides services to the beneficiary when one or more predetermined conditions are met.

In some embodiments, the application further includes information specifying the identity of the bank at the bank.

In some embodiments, the application also includes information demonstrating that the applicant has the ability to pay the predetermined amount in the event of a breach of SB L C.

In some embodiments, the identity of the applicant comprises one or more of the name, address, telephone number, email address, and type of service of the applicant.

In some embodiments, the identity of the beneficiary includes one or more of the beneficiary's name, address, phone number, email address, and type of transaction.

In some embodiments, the one or more predetermined conditions include one or more of a default condition, a revision condition, a revocation condition, an expiration date, and an expiration date.

In some embodiments, at least one of the one or more zero knowledge proofs is generated based on homomorphic encryption.

In some embodiments, the one or more zero knowledge proofs include a range proof and/or a zero test.

In some embodiments, the encryption key used to encrypt the digital version is derived based on a linear secret sharing scheme.

The insurance is made by the first guarantor and the second guarantor to the beneficiary, the insurance being in the form of SB L C, and the insurance specifies that the first guarantor and the second guarantor should pay the beneficiary a predetermined amount when one or more predetermined conditions for executing the insurance are met.

In some embodiments, the first guarantor is a first bank that services the applicant, the second guarantor is a second bank that services the applicant, and the application further includes information certifying that, in the event the applicant breaches SB L C, the applicant has sufficient funds in the first bank and the second bank to pay the predetermined amount.

It should be understood that any combination of the aspects and features described herein may be included according to the methods herein. That is, methods according to the present disclosure are not limited to the combinations of aspects and features specifically described herein, but also include any combination of the aspects and features provided.

The details of one or more embodiments of the disclosure are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.

Drawings

FIG. 1 is a diagram illustrating an example of an environment that may be used to perform embodiments herein.

Fig. 2 is a diagram illustrating an example of an architecture according to embodiments herein.

Fig. 3 is a diagram illustrating an example of a blockchain network according to embodiments herein.

Fig. 4 is a flow diagram illustrating an example of message flow between an internal system of a guarantor and a blockchain network, according to embodiments herein.

Fig. 5 is an example of source code for a backup letter of credit according to embodiments herein.

Fig. 6 is a diagram illustrating an example of cryptographic operations performed on a backup LC according to embodiments herein.

Fig. 7 is a swim lane diagram illustrating an example of a blockchain-based LC issuance process according to embodiments herein.

Fig. 8 is a swim lane diagram illustrating an example of blockchain-based credit withdrawal processing according to embodiments herein.

Fig. 9 is a swim lane diagram illustrating an example of blockchain-based LC expiration processing according to embodiments herein.

Fig. 10 is a swim lane diagram illustrating an example of a blockchain-based LC revision process according to embodiments herein.

Fig. 11 is a swim lane diagram illustrating an example of blockchain-based LC revocation processing according to an embodiment herein.

FIG. 12 is a swim lane diagram illustrating an example of SB L C issuance processing based on the cross-chain technique according to embodiments herein.

Figure 13 is a diagram illustrating an example of a system for implementing a trusted insurance platform enabling trusted insurance according to embodiments herein.

Fig. 14a and 14b are diagrams illustrating an example of using a blockchain-based trusted insurance platform according to embodiments herein.

Fig. 15 depicts an example of a process that may be performed according to embodiments herein.

Fig. 16 depicts an example of modules of an apparatus according to embodiments herein.

Fig. 17 depicts another example of a process that may be performed according to embodiments herein.

Fig. 18 depicts another example of modules of an apparatus according to embodiments herein.

FIG. 19 depicts yet another example of a process that may be performed according to embodiments herein.

Fig. 20 depicts yet another example of modules of an apparatus according to embodiments herein.

Fig. 21 depicts yet another example of a process that may be performed according to embodiments herein.

Fig. 22 depicts yet another example of modules of an apparatus according to embodiments herein.

FIG. 23 depicts yet another example of a process that may be performed according to embodiments herein.

Fig. 24 depicts yet another example of modules of an apparatus according to embodiments herein.

FIG. 25 depicts yet another example of a process that may be performed according to embodiments herein.

Fig. 26 depicts yet another example of modules of an apparatus according to embodiments herein.

FIG. 27 depicts yet another example of a process that may be performed according to embodiments herein.

Fig. 28 depicts yet another example of modules of an apparatus according to embodiments herein.

Like reference numbers and designations in the various drawings indicate like elements.

Detailed Description

Techniques for handling blockchain network-based insurance coverage are described herein. The techniques generally involve receiving, from a computing device associated with an applicant, an application for an insurance made by at least a first insurer to a beneficiary, wherein the application includes information associated with the identity of the applicant, the identity of the beneficiary, and one or more predetermined conditions under which the insurance is to be performed; generating a digital version of the insurance based on information included in the application; encrypting the digital version to generate a ciphertext of the insurance; generating one or more Zero Knowledge Proofs (ZKPs) relating to one or more values associated with the insurance function; and storing the ciphertext of the insurance function and the one or more zero knowledge proofs on the blockchain to the blockchain network, wherein the ciphertext of the insurance function is stored on the blockchain through the consensus of the blockchain nodes after the one or more zero knowledge proofs are successfully verified by the blockchain link points in the blockchain network.

Techniques for blockchain-based LC issuance processing are also described herein. The techniques generally involve receiving ciphertext from a first computing device associated with a first guarantor specifying a digital document of a insurance policy, and one or more zero-knowledge proofs relating to one or more values associated with the insurance policy, wherein the insurance policy is made by the first guarantor to a beneficiary and the digital document specifies one or more predetermined conditions for executing the insurance policy; verifying that one or more zero knowledge proofs are correct; after verifying that the one or more zero knowledge proofs are correct, storing the ciphertext into a blockchain based on performing a consensus algorithm; receiving a first message from a second computing device associated with the beneficiary or a representative of the beneficiary, the first message including the beneficiary's acceptance of the insurance; and updating the status of the insurance policy to indicate that the beneficiary has accepted the insurance policy.

Techniques for blockchain-based credit withdrawal processing are also described herein. The techniques generally involve receiving a ciphertext of a digital document specifying a insurance, and one or more zero-knowledge proofs relating to one or more values associated with the insurance, wherein the insurance is made by at least a first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions under which the insurance is to be performed; verifying one or more zero knowledge proofs; after successful verification of one or more zero knowledge proofs, storing the ciphertext into a blockchain based on executing a consensus algorithm; receiving a withdrawal request for the insurance from a first computing device associated with the beneficiary or a representative of the beneficiary; storing the withdrawal request into a blockchain based on executing a consensus algorithm; communicating a first message regarding the withdrawal request to a second computing device associated with the first guarantor; receiving a second message from a second computing device associated with the first guarantor, the second message indicating that the first guarantor agrees to pay the beneficiary in accordance with the insurance policy; updating the status of the deposit letter stored in the blockchain to indicate that the first guarantor has processed the withdrawal request for the deposit letter; communicating a third message to the first computing device associated with the beneficiary or representative of the beneficiary, the third message indicating that the first guarantor agrees to pay the beneficiary in accordance with the insurance policy; receiving a fourth message from the first computing device associated with the beneficiary or a representative of the beneficiary, the fourth message indicating that the beneficiary has received payment from the first guarantor; and updating the status of the insurance policy stored in the blockchain to indicate that the beneficiary has received payment for the insurance policy.

Techniques for blockchain-based LC expiration processing are also described herein. The techniques generally involve receiving a ciphertext of a digital document that specifies a guarantee and one or more zero knowledge proofs relating to one or more values associated with the guarantee, wherein the guarantee is made by at least a first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions under which the guarantee is to be performed; verifying one or more zero knowledge proofs; after successful verification of one or more zero knowledge proofs, storing the ciphertext into a blockchain based on executing a consensus algorithm; receiving a first message from a first computing device associated with the beneficiary or a representative of the beneficiary, the first message indicating that there are no unpaid claims for the insurance premium; sending a second message to a second computing device associated with the first guarantor to confirm that the first guarantor is disbursed from payment obligations under the insurance premium; receiving a third message from a second computing device associated with the first guarantor, the third message requesting that the status of the insurance policy be changed to expired; and updating a state of the insurance policy stored in the blockchain to indicate that the insurance policy has expired.

Techniques for blockchain-based LC revision processing are also described herein. The techniques generally involve receiving a first ciphertext of a first digital document specifying an insurance from a first computing device associated with at least a first guarantor, and one or more zero knowledge proofs relating to one or more values associated with the insurance, wherein the insurance is made by the at least first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions under which the insurance is to be performed; verifying that one or more zero knowledge proofs are correct; after verifying that the one or more zero knowledge proofs are correct, storing the first ciphertext into a blockchain based on performing a consensus algorithm; receiving a first message from a second computing device associated with the beneficiary or representative of the beneficiary, the first message comprising a request to modify the insurance; sending a second message to the first computing device relating to the request to modify the insurance policy; and receiving, from the first computing device, a second ciphertext of a second digital document specifying a insurance policy, the second digital document representing a modified version of the first digital document, wherein the modification is based on the request.

Techniques for blockchain-based LC revocation processing are also described herein. The techniques generally involve receiving ciphertext of a digital document specifying an insurance policy from a first computing device associated with at least a first guarantor, and one or more zero-knowledge proofs relating to one or more values associated with the insurance policy, wherein the insurance policy is made by the at least first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions under which the insurance policy is to be performed; verifying that one or more zero knowledge proofs are correct; after verifying that the one or more zero knowledge proofs are correct, storing the first ciphertext into a blockchain based on performing a consensus algorithm; receiving a first message from a first computing device associated with at least a first guarantor, the first message comprising a request to revoke a insurance policy; storing a request to revoke a guarantee in a blockchain; sending a second message to a second computing device associated with the beneficiary or representative of the beneficiary, wherein the second message comprises a request to revoke the insurance policy; receiving a third message from the second computing device associated with the beneficiary or representative of the beneficiary, wherein the third message comprises confirmation of acceptance of the revocation insurance policy by the beneficiary; and updating the status of the insurance policy stored in the blockchain to indicate that the insurance policy has been revoked.

Techniques are also described herein for issuing a process based on SB L C of a cross-chain technique, the techniques generally involving receiving, by a blockchain node in a first blockchain network, a cross-chain request for relaying a ciphertext of a digital document to a second blockchain network, wherein the cross-chain request is sent from a first computing device associated with a first guarantor, the digital document specifies an insurance from the first guarantor and one or more predetermined conditions under which the insurance is performed, and the insurance is made by the first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions under which the insurance is performed, storing, based on performing a consensus algorithm, the cross-chain request and the ciphertext into a first blockchain associated with the first blockchain network, receiving, from the second computing device, a message for relaying information between the first blockchain network and the second blockchain network, the message including an invalid warranty block accepted by the beneficiary and stored on a second blockchain network, and a confirmed status of the insurance block indicating that the second blockchain network has been updated on the insurance chain.

The techniques described herein produce several technical effects. In some embodiments, the insurance service may be provided by a plurality of guarantors. The entire life cycle of the service between guarantors may be recorded on the blockchain. For example, the blockchain may store a non-tamperproof and transparent chain of records for interaction between guarantors. Since the records on the blockchain are agreed upon by consensus, all blockchain nodes can easily authenticate and trust them. Using blockchain techniques improves the efficiency of secure transactions when more than two parties are involved, as compared to point-to-point encrypted communications between two parties.

For example, time disputes may arise due to the time that SB L C revoked or expired, particularly when the insurer includes onshore and offshore banks located in different time zones.

In some embodiments, each party involved in a transaction associated with an insurance service may embed a unique Identification (ID) for identifying its identity. The party may also add its digital signature when sending the message over the blockchain network. In this way, the identity of the party can be verified and trusted. The unique ID may also be used to track all transactions performed by the party on the blockchain.

In some embodiments, the insurance policy to be recorded on the blockchain may be encrypted. Encryption keys may be generated and shared between parties involved in related transactions. The guarantor may also provide a Zero Knowledge Proof (ZKP) to consensus nodes of the blockchain network. The consensus node may use zero knowledge proof to verify whether the values in the insurance policy are suitable for valid transactions (e.g., whether the values are within some reasonable range) without knowing the actual values. The consensus node performs consensus only after verifying zero knowledge proof. In this way, the privacy and security of the content of the insurance policy recorded on the blockchain can be ensured.

In some embodiments, the data privacy of the insurance may be further protected based on the use of Trusted Execution Environment (TEE) technology. The trusted execution environment is an isolated and trusted computing environment that may be integrated in a blockchain node in a blockchain network. The trusted execution environment processes the plaintext of the protected content and outputs the ciphertext of the content. Using trusted execution environment technology, the insurance policy can be easily updated inside the trusted execution environment without revealing any content or updates. In addition, the output of the trusted execution environment is encrypted and trusted by all blockchain nodes in the blockchain network, and thus can be efficiently stored into the blockchain after the blockchain nodes have agreed.

Further background is provided for embodiments herein, as noted above, a distributed ledger system (D L S), which may also be referred to as a consensus network (e.g., consisting of point-to-point nodes) and blockchain network, enables participating entities to securely and non-tamperproof conduct transactions and store data.

Blockchains are data structures that store transactions in a transaction-untamperable manner. Thus, the transactions recorded on the blockchain are reliable and trustworthy. A block chain includes one or more blocks. Each block in the chain is linked to the immediately preceding block in the chain by a cryptographic hash value (cryptographic hash) that contains the preceding block. Each tile also includes a timestamp, its own cryptographic hash value, and one or more transactions. Transactions that have been verified by nodes in the blockchain network are hashed and compiled into merkel (Merkle) trees. A Merkle tree is a data structure in which data at leaf nodes of the tree is hashed and all hash values in each branch of the tree are concatenated at the root of the branch (concatenated). This process continues down the tree up to the root of the entire tree where hash values representing all of the data in the tree are stored. Whether the hash value is a hash value of a transaction stored in the tree can be quickly verified by determining whether the hash value is consistent with the structure of the tree.

A blockchain is a decentralized or at least partially decentralized data structure for storing transactions, while a blockchain network is a network of computing nodes that manages, updates, and maintains one or more blockchains by broadcasting transactions, validating transactions, confirming transactions, and the like. As described above, the blockchain network may be provided as a public blockchain network, a private blockchain network, or a federated blockchain network. Embodiments herein are described in more detail with reference to a federated blockchain network. However, it is contemplated that embodiments herein may be implemented in any suitable type of blockchain network.

Typically, a federated blockchain network is private among the participating entities. In a federated blockchain network, consensus processes are controlled by an authorized set of nodes, which may be referred to as consensus nodes, one or more of which are operated by respective entities (e.g., financial institutions, insurance companies). For example, a federation consisting of ten (10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, with each entity operating at least one node in the federated blockchain network.

In some examples, within a federated blockchain network, a global blockchain is provided as a blockchain that is replicated across all nodes. That is, for a global blockchain, all consensus nodes are in a fully consensus state. To achieve consensus (e.g., agree to add a block to a blockchain), a consensus protocol is implemented within a federated blockchain network. For example, a federated blockchain network may implement a Practical Byzantine Fault Tolerant (PBFT) consensus, described in further detail below.

In some examples, network 120 includes a local area network (L AN), a Wide Area Network (WAN), the Internet, or a combination thereof, and connects websites, user devices (e.g., computing devices), and backend systems.

In the depicted example,

computing systems

106, 108 may each comprise any suitable computing system capable of participating as a node in federation blockchain network 102. Example computing devices include, but are not limited to, servers, desktop computers, laptop computers, tablet computing devices, and smart phones. In some examples, the

computing systems

106, 108 carry one or more computer-implemented services for interacting with the federation blockchain network 102. For example, the computing system 106 may host a computer-implemented service, such as a transaction management system, of a first entity (e.g., user a), such as the first entity using the transaction management system to manage its transactions with one or more other entities (e.g., other users). The computing system 108 may host a computer-implemented service, such as a transaction management system, of a second entity (e.g., user B), for example, that the second entity uses to manage its transactions with one or more other entities (e.g., other users). In the example of fig. 1, the federated blockchain network 102 is represented as a Peer-to-Peer network of nodes (Peer-to-Peer network), and the

computing systems

106, 108 provide nodes of first and second entities, respectively, that participate in the federated blockchain network 102.

Fig. 2 depicts an example of an architecture 200 according to embodiments herein. The exemplary concept architecture 200 includes

participant systems

202, 204, 206 corresponding to participant a, participant B, and participant C, respectively. Each participant (e.g., user, enterprise) participates in a blockchain network 212 provided as a peer-to-peer network that includes a plurality of nodes 214, at least some of which record information in a blockchain 216 without tampering. As further detailed in the figure, although a single blockchain 216 is schematically depicted in blockchain network 212, multiple copies of blockchain 216 are provided and maintained on blockchain network 212.

In the depicted example, each

participant system

202, 204, 206 is provided by or represents participant a, participant B, and participant C, respectively, and functions as a respective node 214 in the blockchain network. As used herein, a node generally refers to an individual system (e.g., computer, server) that is connected to the blockchain network 212 and enables the respective participants to participate in the blockchain network. In the example of fig. 2, a participant corresponds to each node 214. However, it is contemplated that one participant may operate multiple nodes 214 within blockchain network 212, and/or that multiple participants may share a node 214. In some examples, the

participant systems

202, 204, 206 communicate with or through the blockchain network 212 using a protocol (e.g., hypertext transfer protocol secure (HTTPS)) and/or using Remote Procedure Calls (RPCs).

The nodes 214 may have different degrees of participation within the blockchain network 212. For example, some nodes 214 may participate in the consensus process (e.g., as miners' nodes that add tiles to the blockchain 216), while other nodes 214 do not participate in this consensus process. As another example, some nodes 214 store a complete copy of blockchain 216, while other nodes 214 store only a copy of a portion of blockchain 216. For example, the data access privileges may restrict blockchain data stored by the respective participants within their respective systems. In the example of fig. 2, the

participant systems

202, 204, 206 store respective full copies 216', 216 ", and 216"' of the blockchain 216.

A blockchain (e.g., blockchain 216 of fig. 2) consists of a series of blocks, each block storing data. Examples of data include transactional data representing transactions between two or more participants. Although "transaction" is used herein by way of non-limiting example, it is contemplated that any suitable data may be stored in the blockchain (e.g., documents, images, video, audio). Examples of transactions may include, but are not limited to, exchanging things of value (e.g., assets, products, services, currency). Transaction data is stored in the blockchain in a tamperproof manner. That is, the transaction data cannot be changed.

The transaction data is hashed prior to being stored in the chunk. The hash process is a process of converting transaction data (provided as character string data) into a hash value of a fixed length (also provided as character string data). It is not possible to perform a de-hash process (un-hash) on the hash value to obtain the transaction data. The hashing process may ensure that even slight changes in the transaction data result in an entirely different hash value. Further, as described above, the hash value has a fixed length. That is, the length of the hash value is fixed regardless of the size of the transaction data. The hash process includes processing the transaction data through a hash function to generate a hash value. Exemplary hash functions include, but are not limited to, Secure Hash Algorithm (SHA) -256 which outputs a 256-bit hash value.

Transaction data for a plurality of transactions is hashed and stored in a block. For example, hash values for two transactions are provided, and themselves are hashed to provide another hash value. This process is repeated until a single hash value is provided for all transactions to be stored in the block. This hash value is called the Merkle root hash value and is stored in the header of the chunk. Any change in a transaction causes its hash value to change and ultimately the Merkle root hash value to change.

The blocks are added to the block chain by a consensus protocol. A plurality of nodes in the blockchain network participate in the consensus protocol and perform the work of adding a block to the blockchain. Such nodes are referred to as consensus nodes. The PBFT introduced above serves as a non-limiting example of a consensus protocol. The consensus node performs a consensus protocol to add a transaction to the blockchain and updates the overall state of the blockchain network.

In more detail, the consensus node generates a chunk header, hashes all transactions in the chunk, and combines the resulting hash values in pairs to generate further hash values until a single hash value (Merkle root hash value) is provided for all transactions in the chunk. This hash value is added to the block header. The consensus node also determines the hash value of the newest block in the blockchain (i.e., the last block added to the blockchain). The consensus node also adds a random number (nonce) value and a timestamp to the chunk header.

Typically, PBFT provides a practical byzantine machine state replication that is tolerant of byzantine errors (e.g., failed nodes, malicious nodes). This is achieved in the PBFT by assuming that a failure will occur (e.g., assuming that there is an independent node failure and/or a manipulated message sent by a common node). In PBFT, consensus nodes are provided in a sequence comprising a primary consensus node and a secondary consensus node. The master consensus node is changed periodically. Transactions are added to the blockchain by agreeing on the global state of the blockchain network by all consensus nodes within the blockchain network. In this process, messages are transmitted between the consensus nodes, and each consensus node proves that the message was received from the designated peer node and verifies that the message was not modified during the transaction.

In PBFT, the consensus protocol is provided in multiple phases with all consensus nodes starting in the same state. First, a client sends a request to a master consensus node to invoke a service operation (e.g., perform a transaction within a blockchain network). In response to receiving the request, the primary consensus node multicasts the request to the backup consensus node. The backup consensus node executes the request and each node sends a reply to the client. The client waits until a threshold number of recoveries are received. In some examples, the client waits to receive f +1 replies, where f is the maximum number of false consensus nodes that can be tolerated within the blockchain network. The end result is that a sufficient number of consensus nodes agree on the order in which records are added to the blockchain, either accepted or rejected.

In some blockchain networks, privacy of transactions is maintained using cryptography. For example, two nodes may encrypt transaction data if they want to maintain transaction privacy so that other nodes in the blockchain network cannot see the details of the transaction. Examples of encryption processes include, but are not limited to, symmetric encryption and asymmetric encryption. Symmetric encryption refers to an encryption process that uses a single key to both encrypt (generate ciphertext from plaintext) and decrypt (generate plaintext from ciphertext). In symmetric encryption, the same key may be used for multiple nodes, so each node may encrypt/decrypt transaction data.

Asymmetric encryption uses key pairs, each key pair comprising a private key and a public key, the private key being known only to the respective node, and the public key being known to any or all other nodes in the blockchain network. A node may encrypt data using a public key of another node, and the encrypted data may be decrypted using a private key of the other node. For example, referring again to fig. 2, participant a may encrypt data using participant B's public key and send the encrypted data to participant B. Participant B can use its private key to decrypt the encrypted data (ciphertext) and extract the original data (plaintext). Messages encrypted using a node's public key can only be decrypted using the node's private key.

Asymmetric encryption is used to provide a digital signature that enables a participant in a transaction to confirm the other participants in the transaction and the validity of the transaction. For example, a node may digitally sign a message, and another node may confirm that the message was sent by the node based on the digital signature of participant a. Digital signatures may also be used to ensure that messages are not tampered with during transmission. For example, referring again to fig. 2, participant a will send a message to participant B. Participant a generates a hash value of the message and then encrypts the hash value using its private key to provide a digital signature as an encrypted hash value. Participant a appends the digital signature to the message and sends the message with the digital signature to participant B. Participant B decrypts the digital signature using participant a's public key and extracts the hash value. Participant B hashes the message and compares the hash values. If the hash values are the same, participant B can confirm that the message did indeed come from participant A and has not been tampered with.

In some embodiments, nodes of and/or in communication with a blockchain network are capable of operating using a Trusted Execution Environment (TEE). At a high level, the trusted execution environment is a trusted environment within the hardware (processor(s), memory) that is isolated from the hardware's operating environment (e.g., Operating System (OS), basic input/output system (BIOS)). In more detail, the trusted execution environment is a separate secure area of the processor that ensures confidentiality and integrity of the execution code and data loaded within the main processor. Within the processor, the trusted execution environment runs in parallel with the operating system. At least part of a so-called Trusted Application (TA) executes within a trusted execution environment and has access to a processor and memory. Through the trusted execution environment, the trusted application is protected from other applications running in the host operating system. In turn, the trusted execution environment cryptographically isolates trusted applications from each other within its interior.

Examples of trusted execution environments include the software protection extension (SGX) provided by intel corporation of santa clara, california, usa. Although SGX is discussed herein by way of example, it is contemplated that embodiments of the present application may be implemented using any suitable trusted execution environment.

SGX provides a hardware-based trusted execution environment. In SGX, the trusted hardware is the die of the Central Processing Unit (CPU), and a portion of the physical memory is isolated to protect the selection code and data. The isolated portion of memory is called an enclave (enclave). More specifically, the enclave is provided as an Enclave Page Cache (EPC) in memory and mapped to an application address space. The memory (e.g., DRAM) includes a random access memory (PRM) reserved for SGX. Random access memory is a contiguous memory space in the basic input/output system level and cannot be accessed by any software. Each enclave page cache is a set of memory (4KB) allocated by the operating system to load application data and code into random access memory. Enclave Page Cache Metadata (EPCM) is the entry address of the corresponding enclave page cache and ensures that each enclave page cache can be shared by only one enclave. That is, a single enclave is able to use multiple enclave page caches, while an enclave page cache is dedicated to a single enclave.

During execution of the trusted application, the processor operates in a so-called enclave mode when accessing data stored in the enclave. Operation in enclave mode forces an additional hardware check for each memory access. In SGX, trusted applications are compiled into a trusted part and an untrusted part. The trusted portion is inaccessible to, for example, an operating system, a basic input/output system, privileged system code, a Virtual Machine Manager (VMM), a System Management Mode (SMM), and so forth. In operation, the trusted application runs and creates an enclave within random memory of the memory. Trusted functions performed by trusted components within the enclave are invoked by untrusted components, and code executing within the enclave treats the data as clear data (unencrypted), and external access to the data is denied. The trusted portion provides the encrypted response to the call and the trusted application continues to execute.

An authentication process may be performed to verify that a desired node (e.g., a trusted portion of a trusted application) is executing securely within a trusted execution environment provided by the SGX. Typically, the authentication process includes the trusted application receiving an authentication request from a challenger (e.g., another node in the blockchain network, a Key Management System (KMS) of the blockchain network). In response, the trusted application requests that it generate a remote authentication, also referred to as a quote, in-flight. Generating the remote authentication includes the local authentication being sent from the enclave to a so-called quote enclave, which verifies the local authentication and converts the local authentication to the remote authentication by signing the local authentication using the asymmetric authentication key. Remote authentication (quote) is provided to the challenger (e.g., the key management system of the blockchain network).

The challenger verifies the remote authentication using a validation verification service. For SGX, intel provides Intel Authentication Service (IAS), which receives remote authentication from a challenger and verifies the remote authentication. More specifically, the IAS processes the remote authentication and provides a report (e.g., an Authentication Verification Report (AVR)) indicating whether the remote authentication is verified. If not, an error is indicated. If verified (the expected code is securely executed in the trusted execution environment), the challenger can start or continue to interact with the trusted application. For example, in response to authentication, the key management system (as a challenger) can issue (e.g., via a key exchange process, such as elliptic curve Diffie-hellman (ecdh)) an asymmetric cryptographic key (e.g., a public and private key pair) to a node executing a trusted execution environment to enable the node to securely communicate with other nodes and/or clients. Additional details of trusted execution environment techniques are described, for example, in PCT application PCT/CN2019/081180, filed 2019, 4, 3, the contents of which are incorporated herein by reference.

The term "insurance policy" may refer to any type of insurance policy that may be applied to a buyer, such as a buyer, who pays the seller with the correct amount of money, such as a credit or documentary credit, if the buyer is unable to pay all the money for the seller before the expiration date, the buyer will pay all or the remaining money for the seller, such as a credit or documentary credit, such as a credit or a documentary credit, such as a buyer may be under a trade agreement with a buyer, such as a bank under a trade name of OC.8652, or a trade name of OC.8652.

SB L C is a bank insurance document, as described above, in which an applicant/debtor (typically a buyer or importer) vouches for a beneficiary/creditor (typically a supplier, seller or exporter), in the event that the creditor presents to the bank evidence of a claim (e.g., by presenting SB L C to the bank), the bank (i.e., issuing bank) may take the place of the applicant/debtor as a debtor in the event of a breach.SB L C may be used to ensure performance of a contract, contract or business transaction flow.

SB L C provides additional insurance for the beneficiary, i.e., to ensure that the beneficiary can receive the debt amount, for example, SB L C is a financial contract provided outside of a marketing contract or purchase order contract between a debtor and a beneficiary, for example, when a buyer (debtor) intends to purchase goods from a seller (beneficiary), the buyer and seller sign a purchase order contract (or agreement) or marketing contract (or agreement) that states the terms of the transaction, such as specifications of the goods, costs of the goods, and the deadline for delivery of the goods and payment, the purchase order contract is an agreement between the buyer and the seller, the bank is not the party for the purchase order contract but the party for the SB L C, the bank issuing SB L C may be referred to as the issuing bank 302 the issuing bank, the debtor may be referred to as the payee 306, in some examples herein, the transaction is between a sale in a first country (on shore) and a bank in a second country (country) (called the issuing bank 302), the bank 306 may also be referred to as the payee 302, and the debt may be referred to as the paying the debt 302, if the debt is not paid for the debt amount, the buyer or the debt when the debt is paid by the buyer(s) under the debt contract, the buyer is on the bank 306, or the debt contract, the buyer is not paid under the paying, or the debt, the buyer, the debt, the buyer, the.

In some embodiments, the credit guarantee amount in SB L C may be considered a loan applied by the applicant and pre-approved by the issuing bank 302. if SB L C is executed before its expiration, the loan is issued to the beneficiary by the recipient bank 306.

SB L C may be practical for business operations with repeated transactions, for example, in long-term or periodic business relationships, it may be ensured that a seller initiating a product delivery obtains a guaranteed fund on a periodic basis with a buyer, or sometimes before payment is received, in which case SB L C may be transacted early in the business relationship and used for all subsequent transactions between the parties until the buyer breaches, or SB L C is revoked or otherwise disabled.

In some embodiments, transactions associated with events in the life cycle of SB L C may be initiated by the issuing bank 302 or the receiving bank 306. for example, the internal systems of the issuing bank 302 may perform internal transaction approval processes and store internally approved transactions on blockchains through the cloud node 304. in some embodiments, the cloud node 304 may be a blockchain link point on the blockchain network 310 that belongs to the issuing bank 302. the cloud node 304 may be managed and controlled by the issuing bank 302 and participate in consensus of the blockchain network 310. blockchain link points in the blockchain network 310 may pre-verify transactions.

Fig. 4 is a flow diagram illustrating an example 400 of message flow between an internal system of a guarantor and a blockchain network, according to embodiments herein. At a high level, the guarantor's internal system 401 may include an Application (APP)402, a database 404, a Key Management System (KMS)406, and a computing and connectivity component 408. In some embodiments, the internal system 401 may include fewer or more components. The internal system 401 is connected to a blockchain network 409 comprising a plurality of blockchain nodes (for illustrative purposes only blockchain node 410 and blockchain node 412 are shown in fig. 4, it being understood that the blockchain network 409 may comprise many additional blockchain nodes).

Application 402 may be a software program for providing an insurance service. Application 402 may be an interface between the applicant of the insurance and the internal system 401 of the guarantor. For example, the application 402 can be used to receive input including identity information, time, amount, conditions, and content of the applicant of the insurance policy, and the like. In some embodiments, data relating to the insurance policy may be stored in database 404. Database 404 may include any memory or database module and may take the form of volatile or non-volatile memory including, but not limited to, magnetic media, optical media, Random Access Memory (RAM), Read Only Memory (ROM), removable media, or any other suitable local or remote memory component. Database 404 may store various objects or data, including classes, frames, applications, backup data, business objects, tasks, web pages, web page templates, database tables, repositories storing business or dynamic information, and any other suitable information including any parameters, variables, algorithms, instructions, rules, constraints, or references thereto associated with the purpose of application 402 or internal system 401.

Exemplary data may include input from the applicant, data relating to the insurance envelope, template and encryption key sent or forwarded by other guarantors involved in the transaction, and so on. Further, database 404 may include any other suitable data, such as VPN applications, firmware logs and policies, firewall policies, security or access logs, print or other reporting files, and other files. In some examples, application 402 may retrieve data from database 404 through a database Application Program Interface (API).

Application 402 may communicate information related to the insurance policy with computing and connecting component 408. In some embodiments, the computing and connecting component 408 may include a trusted computing module 420, a trusted time module 422, and a trusted identity module 424. The trusted computing module 420 may include one or more processors that execute instructions provided by a Software Development Kit (SDK). Exemplary instructions may include performing encryption, generating a digital signature, and/or a zero knowledge proof, or other applicable proof. In some embodiments, one or more data processors may have a Trusted Execution Environment (TEE) that is isolated from the operating system of the one or more processors and configured to provide enhanced privacy and integrity for code and loaded data executing within the one or more data processors.

In some embodiments, the trusted computing module 420 may be configured to record information associated with the applicant of the insurance in accordance with the privacy laws. For example, the trusted computing module 420 may generate a hash value for the record and add the chunk that includes the record and hash value to the blockchain associated with the blockchain network 409 that stores the record associated with the insurance policy.

In some embodiments, the trusted computing module 420 may be configured to provide an authenticated record of steps/operations performed by the application 402 in response to a request for an authenticated record associated with the insurance for the insurance beneficiary. The trusted computing module 420 may also provide a verified timestamp generated by the trusted time module 422, a verified identity generated by the trusted identity module 424, and/or a computing result associated with each of the steps/operations performed by the application 402.

In some embodiments, the encryption keys used to perform encryption and generate digital signatures and certificates may be provided to trusted computing module 420 by key management system 406. In some embodiments, key management system 406 may generate, store, and manage encryption keys. In some embodiments, key management system 406 includes a secure application environment implemented using trusted execution environment technology (e.g., intel SGX). The trusted execution environment may execute one or more software programs or libraries.

In some embodiments, the trusted time module 422 may be configured to generate a timestamp based on national standard time information (e.g., Greenwich Mean Time (GMT), UTC), or time information obtained from a global positioning system. In some embodiments, the trusted time module 422 may synchronize its maintained time with the global time employed by the blockchain link points in the blockchain network 409 to ensure the accuracy of the timestamps stored on the blockchain.

In some embodiments, the trusted time module 422 may be configured to generate timestamps associated with different users using different standard times for financial systems in different regions. For example, the trusted time module 422 may generate a timestamp associated with a first user using a first standard time recognized by an offshore financial system associated with the first user and a timestamp associated with a second user using a second standard time recognized by an onshore financial system associated with the second user, where the first user and the second user are located in different areas having different financial systems.

The trusted identity module 424 may be configured to verify the identity of a user (e.g., applicant or beneficiary) based on one or more of the unique IDs associated with the user. In some embodiments, the unique ID may include at least one of: (i) a mobile phone number, (ii) a credit card number, (iii) a user ID associated with an online payment system, (iv) a user ID associated with an online shopping account, (v) a user ID associated with a music streaming or download account, (vi) a user ID associated with a movie streaming or download account, (vii) a user ID associated with a messaging or chat account, (viii) a user ID associated with an online banking account, (ix) a user ID associated with a taxi-calling service, (x) a user ID associated with an online food ordering service, (xi) a social security number; (xii) A driver license number, (xiii) a passport number, (xiv) a user ID associated with an online gaming service, (xv) an ID issued by a government entity, (xvi) one or more fingerprints, (xvii) one or more voiceprints, or (xviii) iris information.

In some embodiments, the unique ID may also include a user's Decentralized Identity (DID). the decentralized identity may include a uniform resource locator (UR L) scheme identity, an identity for the decentralized identity method, and an identity specific to the decentralized identity method the decentralized identity may point to a corresponding decentralized identity document which may include descriptive text in a preset format (e.g., JSON-L D) relating to the owner of the decentralized identity and the decentralized identity, the decentralized identity may serve as a Uniform Resource Identity (URI) for locating the decentralized identity document, the decentralized identity document may include various attributes such as context, decentralized identity subject, public key, authentication, authorization and proxy, service endpoint, creation, update, proof, and extensibility, and the decentralized identity document may define or point to resources defining a number of operations which may be performed with respect to the decentralized identity, in the examples described herein, the decentralized identity conforms to the requirements of the application filed by the corporation of the W3, the CN 36C, but may also specify additional information on the date of filing PCT/369 in the above PCT application 369/369, the filing date 369.

In some embodiments, the trusted identity module 424 may be configured to authenticate different users located in different areas with different financial systems by using different identities. For example, the trusted identity module 424 may be configured to verify the identity of a first user using at least one of a first set of identifications recognized by a first financial system associated with the first user, and to verify the identity of a second user using at least one of a second set of identifications recognized by a second financial system associated with the second user, where the first user and the second user are located in different areas having different financial systems.

In some examples, the compute and connect component 408 may also include a router 426 that may route information processed by one or more processors to a blockchain node 410 in a blockchain network 409 communicatively coupled to the internal system 401 as previously described, the blockchain node 410 may be a cloud node that may sign and/or verify messages and communicate with other blockchain nodes, the blockchain node 410 may also be a consensus node in the blockchain network 409 with a consensus process, in some embodiments, communications within and between the internal system 401 and the chain blockchain network 409 may be performed based on a secure communication protocol such as hypertext transfer protocol security (HTTPS) or transport layer security (T L S).

In the SB L C example, the blockchain nodes may be associated with banks, credit unions, trusted companies, lending companies, insurance companies, investment institutions, management institutions, etc. once a transaction is added, the transaction becomes untrustworthy and the parties may trust them as proof of the corresponding warranty service or treatment.

The blockchain enables an application 402 providing the insurance service to maintain a verified record of information (e.g., who, what, and when) about events occurring during each of a number of steps or key points in time of the service.

In this example, SB L C source code 500 includes SB L C number ("sblcNo"), SB L1C type ("sblcType"), code of the issuing bank ("issueBank code"), code of the payee ("beneficial Bank code"), maximum loanable amount in numeric and textual form ("maxAggregated Sum", "maxAggregated SumInWord"), applicant name ("principal"), beneficiary name ("borrower"), SB L C expiration date and time ("expirryDatem"), SB L C validation date and time ("effetevanteTime"), SB L C application date and time ("applicationDatime"), remaining loanable amount ("expirationDatateSum"), actual amount in SB L C ("AmtoDatateTime"), list of actual loanable amounts in terms ("Amoto", "SB L C", see Date "," SB L C application date and time ("appletatemtime"), and other examples of source code 500 including SB 387 information, SB L C number ("sbc number"), SB 462C number ("sbc number"), SB 463C information 500, SB L C information, and other examples of possible loanable amounts in which include fewer examples.

SB L C type may represent the type of SB L C the types of SB L C may include performing reserve credit, pre-paid reserve credit, tendering/bidding reserve credit, anti-vouching reserve credit, financing reserve credit, direct payment reserve credit, insurance reserve credit, business reserve credit, etc. the maximum loanable amount may represent the total amount of the loan that the issuing bank may approve the applicant.

For example, as discussed in the description of FIG. 4, encryption of SB L C may be performed by calculation and connection component 408 before sending encrypted SB L C to blockchain node 410 for consensus.

In some embodiments, the issuing bank (e.g., 302 in FIG. 3) may also generate a zero knowledge proof associated with SB L C the zero knowledge proof is provided with the encrypted SB L C to the blockchain nodes so that the blockchain node may verify the legitimacy of SB L C without knowing the contents of SB L C after verifying that SB L C is legitimate, the blockchain node may perform a consensus to record encrypted SB L C on the blockchain.

FIG. 6 is a diagram illustrating an example 600 of the cryptographic operations performed on SB L C620 according to embodiments herein.A Bank A602 and Bank B604 are assumed to be two joint guarantors of SB L C620 in other words Bank A602 and Bank B604 are issuing banks in other words Bank C606 is the receiving bank of SB L C620.Bank D608 may be a bank that does not participate in the related transactions of SB L C620 As previously described, cryptographic keys may be negotiated between parties participating in the related transactions of SB L C620. in this example 600, the parties include Bank A602, Bank B604 and Bank C606. the cryptographic keys agreed to by the parties may be used to encrypt the SB L C620 string or add a digital signature 612. Bank D608, which is not a party to the transaction, is unable to decrypt the encrypted SB L C.

Bank A602 and Bank B604 may also generate one or more zero knowledge proofs of values associated with SB L C620, such zero knowledge proofs may include proofs under a homomorphic encryption scheme 614, range proofs 616, and/or zero tests 618. a homomorphic encryption scheme 614 may be used to encrypt the maximum loanable amount, actual loan amount, and remaining loanable amount, respectively.

In some embodiments, a range attestation may be used to attest that an amount is within a range without revealing an actual amount. In some examples, bank a 602 and bank B604 may provide range proofs to indicate that the maximum loanable amount is within a reasonable range. For example, a reasonable range may be set to 0 to 2⁴⁰For example, after SB L C expires or is clear of the loan, a zero test may be provided to prove that the actual loan amount in SB L C620 is zero, the encrypted SB L C and zero knowledge proof may form the encrypted ciphertext of SB L C622 to be verified by the blockchain node in blockchain network 624.

In addition or alternatively, the trusted execution environment may be used to provide data privacy for SB L C content As previously described, the trusted execution environment processes plaintext and outputs ciphertext hi some embodiments, the plaintext of SB L C may be processed inside the trusted execution environment, for example, when Bank A602 initiates a revision or a status update to SB L C, such as revising the vouch-for amount of SB L C, accepting or revoking S L BC, a corresponding update may be made on the plaintext of SB L C inside the trusted execution environment.

The following description provides various embodiments of blockchain-based processing associated with a lifecycle of a letter of credit SB L C is used as an example of a letter of credit for illustrative purposes other types of letters of credit or warranties may be applicable to processing according to embodiments herein.

Fig. 7 is a swim lane diagram illustrating an example of a blockchain-based LC issuance process 700 according to embodiments herein. In this example, the LC is a spare LC, but the same principles can be applied to other types of LC. The participants of process 700 may include applicant 702, issuing bank 704, blockchain network 706, receiving bank 708, and beneficiary 710. As previously mentioned, applicant 702 is typically a buyer of a commercial transaction. The issuing bank 702 is typically the buyer's offshore bank. The beneficiary 710 is typically the seller of the commercial transaction. The collection bank 708 is typically the seller's bank that is on shore. In some embodiments, the collection bank 708 may act as a representative of the beneficiary 710 to interact with the issuing bank 704 through the blockchain network 706.

At 712, applicant 702 may submit an application for SB L C to issuing bank 704, in some embodiments, applicant 702 and beneficiary 710 may agree on the terms of SB L C, such as a secured payment amount or a secured loan amount in SB L C. the secured payment amount for beneficiary 710 may be considered a secured loan amount for applicant 702. in the event that applicant 702 cannot pay the secured amount owed to beneficiary 710, the insurer will pay the secured amount to beneficiary 710 and provide a loan of the same amount to applicant 702. for example, the secured payment amount or secured loan amount may be the amount of money involved in the commercial transaction between applicant 702 and beneficiary 710, such as the price of goods the buyer intends to purchase from the seller. the application may be submitted electronically either in physical form or through a website or APP of the bank (e.g., a client-side version of application 402 as discussed in the description of FIG. 4. in general, applicant 702 may submit an application as some additional information in the case of an applicant's identity information.

The credit information may include one or more of the applicant's credit history, account information associated with the issuing bank 704, bank notes, escrow account information, or other information that may indicate that the applicant has sufficient credit to repay the secured loan amount in SB L C.

The issuing bank 704 may enter or store the information in the application to the bank's internal system after receiving the application.information entry may be performed by the application 402 as discussed in the description of FIG. 4, for example.

In some examples, internal approval process 714 may involve issuing bank 704 verifying whether any required information for approval is missing in the application, if any required information is missing, the application may be rejected (716a), and issuing bank 704 may request that applicant 702 replenish the missing information, in the event of a default, issuing bank 704 may also verify whether applicant 702 has sufficient lines to repay the vouched-for payment amount or the vouched-for loan amount in SB L C.

If applicant 702 accepts the offer, SB L C may be approved at the accepted amount, in some examples, the issuing bank 704 may withhold a secured payment amount or a secured loan amount from the applicant's bank account until the payment is issued to the acquiring bank 708 or SB L C is revoked or expired.

After approval of SB L C at 716b, the issuing bank 704 may finalize the SB L C source code, encrypt the SB L C source code and generate the attestation (e.g., zero knowledge attestation.) as discussed in the description of fig. 6, the SB L C source code may be encrypted using an encryption protocol negotiated with the receiving bank 708.

In some examples, updating and recording traceable, irreversible, and tamper-resistant SB L C transactions may be accomplished using smart contracts without involving third parties, which may ensure a secure, trusted record of the entire SB L C lifecycle.

In some embodiments, the forensics line 704 may submit a request to an associated cloud node (e.g., block chain node 410 discussed in the description of FIG. 4), and the cloud node may make a smart contract call.

In operation, the cloud node may generate a smart contract that includes templates to perform operations such as updating the cryptogram of SB L C, updating the state of SB L C, sending messages to the issuing bank 704, and sending messages to the receiving bank 708.

In some embodiments, the cloud node may further define rules in the smart contract template for updating different aspects of SB L C, or issue authorizations to different entities for updating SB L C or its state.

In some examples, the cloud node generates and submits transactions of the smart contracts to the blockchain network 706. The transactions of the smart contract 706 may include the program and initiator of the smart contract. The block link points in the block chain network verify the transactions of the intelligent contracts. After a block link point successfully validates a transaction of a smart contract, the smart contract may be deployed in a distributed manner in the block link network 706 and have a unique smart contract address from which the smart contract may be invoked.

At 718, encrypted SB L C may be published on the blockchain through a consensus process of blockchain nodes in the blockchain network 706. for example, a blockchain node (e.g., a cloud node) of an internal system connected to the issuing bank 704 may submit the encrypted SB L C and a certificate to the blockchain network 706 for consensus.

After recording the encrypted SB L C on the blockchain, the receiving bank 708 may retrieve the encrypted SB L C and perform decryption based on the encryption key negotiated with the issuing bank 702. then, at 720, the receiving bank 708 may confirm acceptance of SB L C, or in the event of any typing error, request a revision to SB L C at 724.

If the payee bank 708 detects a typing error in SB L C, it may request a revision to SB L C at 724 by submitting the proposed revision to the blockchain network 706 for consensus processing, if the revision is related to the monetary value in SB L C, the payee bank 708 may generate evidence for a validity check of the proposed revision.

After agreement, the proposed revision may be recorded on the blockchain and communicated to the issuing bank 704 at 726. for example, a smart contract on the blockchain may generate a message regarding the proposed revision and communicate the message to the issuing bank 704. at 728, the issuing bank 704 performs an internal approval process for the proposed revision after approval, the issuing bank 704 may revise at 730 SB L C, encrypt the revised SB L C, and submit it to the blockchain network 706 to update the SB L C on the blockchain. after approval, for example, an update to SB L C on the blockchain may be accomplished by invoking a smart contract on the blockchain, where the smart contract is configured to update SB L C. at 732, a message indicating that SB L C has been revised is communicated to the receiving bank 708 by the blockchain network 706. for example, the message may be generated by the blockchain and sent by the smart contract to the receiving bank at 734, the receiving bank confirms acceptance of the SB 3526C, and may request the update of the status of the smart contract on the blockchain at 36736C — for example, update the status of the SB L, the receiving bank may be updated at 36493 3C, the status of the block chain may be updated by invoking the smart contract on the blockchain (36724).

Herein, when we say that a message or document is sent to or from an entity, such as applicant 702, an offshore (issuing) bank 704, an onshore (receiving) bank 708, or a beneficiary 710, we mean that the message or document is sent to or from a computing device associated with the entity. In process 700, an entity may send or receive one or more messages or documents, where the computing device used to send or receive a particular message or document may be different from the computing device used to send or receive other messages or documents. The computing device associated with the entity may be, for example, a computer local to the entity or a cloud computing device accessible to the entity over a network.

Fig. 8 is a swim lane diagram illustrating an example of a blockchain-based LC withdrawal process 800 according to embodiments herein. In this example, the LC is a spare LC, but the same principles can be applied to other types of LC. The participants of process 800 may include an offshore (issuing) bank 704, a blockchain network 706, an onshore (receiving) bank 708, and a beneficiary 710.

At 802, the beneficiary 710 or a representative of the beneficiary 710 may submit a withdrawal request of the SB L C to the payee bank 708 when the applicant 702 violates, e.g., does not pay after a payment due date agreed upon by both parties in a marketing or purchase order agreement, the beneficiary 710 may initiate the withdrawal request, in some embodiments, the withdrawal request 802 may also include a support document to support its request.

At 804, the collection bank 708 may perform an internal approval process to review the withdrawal request. In some embodiments, the collection bank 708 may perform a preliminary check to determine if the necessary files are included in the withdrawal request. Collection bank 708 may not have a substantial review of the contents of the claim and the proof. For example, the collection bank 708 may check whether the withdrawal request includes at least a claim with corresponding proof. If the included files are sufficient to support the preliminary claim, the withdrawal bank 708 may approve the withdrawal request at 806 b. Otherwise, the payee bank 708 may decline the withdrawal request at 806a and ask the beneficiary 710 to supplement or correct the information. If the withdrawal row 708 approves the withdrawal request at 806b, the withdrawal row 708 may submit the withdrawal request at 812 to the issuing bank 704 via the blockchain network 706, the request including a claim (with proof). In some examples, the collection bank 708 may encrypt the withdrawal request before sending the withdrawal request to the blockchain network 706 for consensus.

At 814, the blockchain link points in blockchain network 706 may perform consensus to record the withdrawal request and notify the issuing bank 704 that the withdrawal request has been submitted. for example, recording and notification of the withdrawal request may be performed by invoking an intelligent contract on the blockchain associated with blockchain network 706. at 816, the issuing bank 704 may perform an internal approval process after decrypting the claim, based on the review of the claim and the proof included in the claim, if the claim satisfies one or more conditions indicating a violation of the agreement between applicant 702 and beneficiary 710 defined in the terms of SB L C and the proof is sufficient to support the claim, the issuing bank 704 may approve the withdrawal request at 818 a. otherwise, the issuing bank 704 rejects the withdrawal request at 818 b.

If the withdrawal request is approved at 818a, issuing bank 704 may pay receiving bank 708 and update the status of SB L C to "processed claim" at 820. for example, payment may be made to receiving bank 708 by a bank transfer service such as wire transfer based on the identity information of receiving bank 708 included in SB L C.

At 822, the block chain network 706 records the state update of SB L C by consensus and passes the message to the payee bank 708. at 824, the payee bank 708 acknowledges receipt of the payment and updates the SB L C state to "processed payment". at 826, the block chain network 706 updates the SB L C state to "processed payment" accordingly.

If the withdrawal request is rejected at 818b, the issuing bank 704 may send a repudiation notification to the collection bank 708 through the blockchain network 706 at 828, the blockchain network 706 records the repudiation notification at 830 and passes the message to the collection bank 708, the collection bank 708 may acknowledge receipt of the repudiation notification and update the status of SB L C to "claim completed" at 832, the blockchain network 706 updates the status of SB L C to "claim completed" accordingly at 834.

FIG. 9 is a swim lane diagram illustrating an example of a blockchain-based LC expiry process 900 according to embodiments herein. In this example, the LC is a spare LC, but the same principles can be applied to other types of LC. Participants of process 900 may include an offshore (issuing) bank 704, a blockchain network 706, and an onshore (receiving) bank 708.

As previously described, SB L C may have an issuance date, an effect date, and an expiration date provided by issuing bank 704 that are agreed upon by applicant 702 and beneficiary 710. the insurance policy in SB L C is effective from the effect date to the expiration date.the expiration date may be determined from the time zone governing the jurisdiction of SB L C. the expiration date may also be based on the time zone agreed upon by applicant 702 and beneficiary 710, such as the time zone in which issuing bank 704 is located, the time zone in which payee bank 708 is located, or GMT. typically, if applicant 702 agrees to pay beneficiary 710 before a certain expiration date, then the expiration date of SB L C will be several days (e.g., five working days) after the payment expiration date.

On the due date of SB L C, the receiving bank 708 may determine if there is an unpaid claim at 912 if there is an unpaid claim, then the receiving bank 708 may send a request message requesting an extension of the validity period of SB L C until the guaranteed loan amount in SB L C is paid to end the claim.

At 916, the issuing bank 704 performs an internal approval process on the received message if the message is a request message requesting an extension of the validity period of SB L C, the issuing bank 704 may update the terms in SB L C after internal approval to reflect the requested extension at 918, if the message is an acknowledgement message, the issuing bank 704 may update the SB L C status to expired, the issuing bank 704 sends a message transmission to the blockchain network 706 regarding the status update, and the blockchain network 706 updates the status of SB L C recorded on the blockchain to "expired" at 920.

FIG. 10 is a swim lane diagram illustrating an example of a blockchain based credit revision process 1000 according to embodiments herein, in which the credit is a spare credit, but the same principles may apply to other types of credit, the participants of process 1000 may include an applicant 702, an offshore (issuing) bank 704, a blockchain network 706, an onshore (payee) bank 708, and a beneficiary 710. in some embodiments, process 1000 is performed after applicant 702 makes a partial payment to beneficiary 710 based on a purchase order agreement between the two parties. in some examples, a partial payment may be made through a traditional financial channel, such as an electric transfer between issuing bank 704 that serves applicant 702 and a payee bank 708 that serves beneficiary 710. assuming that the guaranteed amount in SB L C covers the full payment of the order, applicant 702 may request that beneficiary 710 confirm that partial payment has been made since the guaranteed amount in SB L C has already been made, applicant 702 may not request that the full amount of the guaranteed amount of the purchase order exceeds the amount of the full bank by deducting the amount of the guaranteed amount of the bank C, and thus the full amount of the applicant 702 may not be requested by paying the SB 63704 for the payee of the full amount of the SB 3652.

At 1002, the beneficiary 710 receives a partial payment from the applicant 702 prior to the expiration date of SB L C, then, the beneficiary 710 may notify the payee bank 708 of the partial payment, at 1004, the payee bank 708 may validate the partial payment and submit a confirmation to the issuing bank 704 and applicant 702 over the blockchain network 706, at 1006, the blockchain link points in the blockchain network 706 agree to agree and store a confirmation of the partial payment on the blockchain and communicate the confirmation to the issuing bank 704 and/or applicant 702.

In response to identifying the confirmation of the partial payment stored on the blockchain, applicant 702 may request that issuing bank 704 submit a revision request to SB L C to reduce the warranty loan amount at 1008 the reduced amount may equal the amount of the partial payment confirmed by beneficiary 710 received through blockchain network 706 at 1010, issuing bank 704 may perform an internal approval process to review the revision request in some embodiments, issuing bank 704 may perform an internal approval process with reference to information stored on the blockchain.

At 1016, the block link points in the block chain network 706 agree to store the ciphertext of the revised SB L C on the block chain and pass a message to the recipient bank 708 about the revised SB L C, for example, the block link points connected to the issuing bank 704 may invoke a smart contract on the block chain to initiate a consensus process at the block link points at 1018, the recipient bank 708 performs an internal approval process to review the revised SB L C. if approved, the recipient bank 708 may confirm acceptance of the revised SB L C at 1022. in some examples, the recipient bank 708 may submit the confirmation to the block chain network 706 for storage on the block chain.

At 1026, the blockchain network 706 stores the rejection decision on the blockchain and passes a message to the issuing bank 704 regarding the rejection reason and the proposed revision.

At 1032, the blockchain node in the blockchain network 706 agrees to store the ciphertext of the revised SB L C on the blockchain, stores the ciphertext of the revised SB L C on the blockchain, and passes a message to the payee bank 708 about the revised SB L C.

FIG. 11 is a swim lane diagram illustrating an example of a blockchain based LC revocation process 1100 according to embodiments herein, in which the LC is a spare LC, but the same principles may apply to other types of LC.A participant of the process 1100 may include an applicant 702, an offshore (issuing) bank 704, a blockchain network 706, an onshore (payee) bank 708, and a beneficiary 710. in some embodiments, the process 1100 is performed after the applicant 702 makes a full payment to the beneficiary 710 based on a purchase order agreement between the two parties.in some examples, a full payment may be made through a traditional financial channel, such as an electronic transfer between the issuing bank 704 servicing the applicant 702 and the payee bank 708 servicing the beneficiary 710. assuming that a guaranteed amount in SB L C covers all payments of the order, then the applicant 702 may request the beneficiary 710 to confirm that full payment has been made.

At 1102, the beneficiary 710 receives the full payment from the applicant 702 before the expiration date of SB L C the beneficiary 710 may then notify the payee bank 708 about the full payment, at 1104, the payee bank 1004 may confirm the full payment and submit a confirmation to the issuing bank 704 and applicant 702 over the blockchain network 706. at 1106, the blockchain network 706 may agree on a consensus at the blockchain link point in the blockchain network 706 and store the confirmation of the full payment on the blockchain.

In response to identifying confirmation of the full payment stored on the blockchain, applicant 702 may request issuing bank 704 to submit a revocation request to SB L C at 1108. at 1110, issuing bank 704 may perform an internal approval process for the revocation request.in some embodiments, issuing bank 704 may perform an internal approval process with reference to information stored on the blockchain.

At 1116, the blockchain network 706 stores the SB L C status update on the blockchain and passes a message to the receiving bank 708 related to the revocation request.

FIG. 12 is a swim lane diagram illustrating an example of a SB L C issuance process 1200 based on cross-chain technology according to embodiments herein, participants of the process 1200 may include an applicant 702, an issuing bank 704, a blockchain network 1703, a relay 705, a blockchain network 2707, and a collection bank 708. the cross-chain technology has been developed to facilitate interaction and interoperability between different blockchains.

In some embodiments, the relay 705 may be used to facilitate interaction between the blockchain network 1703 and the blockchain network 2707. The relay 705 is a trusted entity and may take various forms. In some examples, the relay 705 may be a blockchain node of the blockchain network 1703 and the blockchain network 2707. In some examples, the relay 705 may be a trusted node that performs data validation before relaying cross-link data between the blockchain network 1703 and the blockchain network 2707. In some examples, the relay 705 may also simply relay cross-chain data without performing data validation. In some examples, the relay 705 may be a blockchain network that performs data validation by consensus before relaying cross-chain data between the blockchain network 1703 and the blockchain network 2707.

The trustworthiness of the relay 705 may be achieved based on various techniques of embodiments herein. For example, the techniques may include trusted execution environments, authority attestation (POA), secure multiparty computing, zero knowledge attestation, consensus algorithms, and so on.

At 1212, applicant 702 may submit an application for SB L C to the issuing bank 704. As discussed in the description of FIG. 7, applicant 702 and the beneficiary may agree on the terms of SB L C (e.g., the guaranteed loan amount in SB L C.) after receiving the application, the issuing bank 704 may enter or store the information in the application to the bank's internal system.

In some examples, the internal approval process may involve the issuing bank 704 verifying whether any required information for approval is missing in the application, if any required information is missing, the application may be rejected, and the issuing bank 704 may request that the applicant 702 replenish the missing information, in the event of a default, the issuing bank 704 may also verify whether the applicant 702 has a sufficient amount to repay the vouch-for loan amount in SB L C.

At 1216, a cross-chaining request may be stored on a first blockchain associated with blockchain network 1703 through consensus and passed to relay 705. for example, a blockchain link point (e.g., a cloud node) connected to an internal system of the issuing bank 704 may submit a cross-chaining request for consensus. after the blockchain link point verifies the proof of validity of SB L C, the blockchain link point may perform consensus and store encrypted SB L C in the block to be appended to the first blockchain. details of generating and recording encrypted SB L C in the blockchain have been discussed previously in the description of FIGS. 5 and 6.

At 1218, relay 705 may relay the cross-link request to block-chain network 2707. The relay 705 may be a trusted entity for both the blockchain network 1703 and the blockchain network 2707. The system is configured to ensure that cross-chain data to be relayed is actually stored on the first blockchain, thus making it trustworthy. In some embodiments, the relay 705 may monitor the cross-chain message and relay the message after verifying that the message is stored on the first blockchain. In some embodiments, a block link point in a block chain network may generate a proof. The relay 705 may retrieve and verify the proof to confirm that the cross-chain message originated from the first blockchain. In some embodiments, the validation data may be pre-stored in a Simple Payment Validation (SPV) node of the destination area blockchain network. The SPV node may obtain the cross-chain data through the relay 705, verify the authenticity of the cross-chain data, and forward the verified cross-chain data to the destination. Additional details and embodiments of relaying cross-link data are described in, for example, PCT application PCT/CN2019/106610 filed on 19/9/2019 and PCT application PCT/CN2020/071574 filed on 11/1/2020, which are incorporated herein by reference.

At 1220, blockchain network 2707 records the cross-chain request with consensus and passes the encrypted SB L C to collection bank 708. collection bank 708 may perform decryption of encrypted SB L C based on the encryption key negotiated with issuing bank 702. collection bank 708 may then acknowledge acceptance of SB L C at 1222 and request blockchain network 2707 to record the updated SB L C state on a second blockchain associated with blockchain network 2707 with consensus.

At 1224, blockchain network 2707 may update the SB L C status on the second blockchain to "issued" through consensus and pass the acknowledgement to relay 705 at 1226, relay 705 may verify that SB L C was issued on the second blockchain, provide proof of verification, and relay the acceptance acknowledgement to blockchain network 1703.

At 1228, the blockchain node in blockchain network 1703 may verify that SB L C is a certification issued on the second blockchain and pass the verification result and acceptance confirmation to the issuing bank 704. in some embodiments, a root of trust (RoT) may be deployed on the blockchain node in blockchain network 1703.

At 1230, the issuing bank 704 may invalidate SB L C stored on the first blockchain in response to receiving the verification result and the receiving bank 708 has confirmed acceptance of SB L C to ensure that only one issued SB L C is valid so that the beneficiary cannot obtain double payment from SB L C stored on the first and second blockchains.

Herein, when describing processes for processing events related to an insurance life cycle, such as

processes

700, 800, 900, 1000, 1100, and 1200, for ease of description, we may say that a computing device associated with an entity sends a first message, receives a second message, sends a third message, receives a fourth message, and so on. It should be understood that the same or different computing devices associated with the entities may be used to send or receive the first message, the second message, the third message, the fourth message, and so on. Thus, for example, depending on the context, the phrase "computing device associated with an entity" may represent a plurality of computing devices associated with the entity, wherein a first one of the plurality of computing devices performs a first task, a second one of the plurality of computing devices performs a second task, and so on.

Fig. 13 is a diagram illustrating an example of a system for implementing a blockchain-based trusted insurance platform 1300 that enables trusted insurance coverage according to embodiments herein. The trusted insurance platform 1300 may provide services related to various phases of the insurance life cycle. In this example, the trusted insurance platform 1300 provides services to a first applicant 1322a of a first insurance, a second applicant … of a second insurance, an N1 applicant 1322b of an N1 insurance (collectively 1322), a first guarantor 1324a, a second guarantor …, an N2 guarantor 1324b (collectively 1324), a first beneficiary 1326a, a second beneficiary …, an N3 beneficiary 1326b (collectively 1326), a first beneficiary agent 1342a, a second beneficiary agent … …, and an N4 beneficiary agent 1342b (collectively 1342).

For example, the first applicant 1322a may be a buyer that intends to purchase goods from a beneficiary 1326a, which may be a seller of the goods. The first applicant 1322a may apply for a first warranty issued by a first guarantor 1324a, which may be an issuing bank (or offshore bank) that provides services to the first applicant 1322 a. The first guarantor 1324a may interact with a first beneficiary agent 1342a, which first beneficiary agent 1342a may be a beneficiary bank (or bank on shore) that provides services to a first beneficiary 1326 a.

In some examples, the insurance may involve the applicant 1322, the guarantor 1324, the beneficiary 1326, and the beneficiary agent 1342. The applicant 1322 may have an agreement with the beneficiary 1326 wherein the applicant 1322 agrees to pay the beneficiary 1326a predetermined amount before a predetermined due date. The guarantor 1324 issues a guarantee that the beneficiary 1326 will receive the predetermined amount before the predetermined due date in the event that the applicant 1322 cannot pay the entire predetermined amount before the due date. The guarantor 1324 interacts with the beneficiary agent 1342 to perform processing related to the insurance policy.

The trusted insurance platform 1300 is configured to provide tools (e.g., web-based ports and interfaces and smart contracts) that enable the applicant 1322, guarantor 1324, beneficiary 1326, and beneficiary agent 1342 to conveniently and timely implement the processing associated with various events throughout the life of the insurance. For example, trusted insurance platform 1300 may provide a web-based user interface that facilitates application, issuance, revision, withdrawal, expiration, and revocation of insurance policies of the relevant parties, and facilitates recording of information in one or more blockchains related to application, issuance, revision, withdrawal, expiration, and revocation of insurance policies.

For example, the insurance may be a letter of credit, and the trusted insurance platform 1300 may provide tools to implement the blockchain-based letter of credit issuance process 700 of FIG. 7, the blockchain-based letter of credit withdrawal process 800 of FIG. 8, the blockchain-based letter of credit expiration process 900 of FIG. 9, the blockchain-based letter of credit revision process 1000 of FIG. 10, the blockchain-based letter of credit revocation process 1100 of FIG. 11, and the cross-chain technology-based SB L C issuance process 1200 shown in FIG. 12.

In general, each guarantor 1324 may issue one or more letters to each of one or more applicants 1322, and each applicant 1322 may apply one or more letters from each of one or more guarantors 1324. One or more guarantors 1324 may issue a letter of guarantee to applicant 1322. The guarantor 1324 may issue a letter of guarantee to one or more applicants 1322. Each insurance may have one or more beneficiaries.

In some embodiments, trusted insurance platform 1300 includes an insurance document generation module 1302, an insurance document revision module 1304, an insurance document encryption module 1306, an insurance issuance process module 1308, an insurance fulfillment process module 1310, an insurance expiration process module 1312, an insurance revocation process module 1344, an insurance cross-chain process module 1346, a zero knowledge proof generation module 1348, a user interface module 1314, and a blockchain process module 1316. the insurance document generation module 1302 is configured to generate an insurance document, e.g., source code of an insurance, such as source code 500 of SB L C. for example, in process 700 of FIG. 7, an offshore (issuing) bank 704 may use its own system or use the insurance document generation module 1302 to generate SB L C. in some embodiments, the insurance document generation module 1302 is a web-based tool that provides an insurance document template that allows the offshore bank 704 to conveniently generate an insurance document.A insurance document revision module 1304 is configured to facilitate equivalent processing 1000 of the insurance document similar to process 700 and/or process 1000 in FIG. 10 of FIG. 7.

The insurance document encryption module 1306 is configured to encrypt the insurance document and generate an encryption key. The zero knowledge proof generation module 1348 is configured to generate a zero knowledge proof. The insurance issuance process module 1308 is configured to facilitate issuance of an insurance policy using a process equivalent or similar to the process 700 of fig. 7. The insurance fulfillment processing module 1310 is configured to process processes related to fulfilling insurance, such as processing a withdrawal request using a process equivalent or similar to process 800 in fig. 8.

The insurance expiration processing module 1312 is configured to process insurance expiration-related processing using processing equivalent or similar to the process 900 of FIG. 9. the insurance revocation processing module 1344 is configured to process insurance revocation-related processing using processing equivalent or similar to the process 1100 of FIG. 11. the insurance cross-chain processing module 1346 is configured to process processing involving multiple blockchain networks, such as using processing equivalent or similar to the process 1200 of FIG. 12 to facilitate cross-chain technology-based SB L C issuance processing.

Information relating to the insurance and events in the insurance lifecycle may be recorded in blockchain 1334 maintained by blockchain network 1328. Blockchain processing module 1316 acts as a blockchain link point 1330 in blockchain network 1328 and maintains a local copy 1318 of blockchain 1334. Blockchain 1318 may include records, such as 1318a, 1318b, 1318 c. Other entities, such as entity 1336, may participate as blockchain link points 1332 in blockchain network 1328, where entity 1336 may include a computer server 1338 that maintains a local copy 1340 of blockchain 1334 and performs mining and/or consensus operations.

In some implementations, the blockchain-based trusted insurance platform 1300 can provide cloud services to the applicant 1322, the guarantor 1324, the beneficiary 1326, and the beneficiary agent 1342 to facilitate various processes related to processing insurance. Each of the applicant 1322, the guarantor 1324, the beneficiary 1326, and the beneficiary agent 1342 has an account on the platform 1300, and private data belonging to each entity is not shared with other entities. Some modules may process data that is private to a particular application, a particular guarantor, a particular beneficiary, or a particular beneficiary representative, and that private data is not accessible to any other party.

For example, insurance document generation module 1302 can be used by guarantor 1324 to generate an insurance document. The insurance document encryption module 1306 may be used by the guarantor 1324 to generate an encryption key and generate a ciphertext of the insurance document. The zero knowledge proof generation module 1348 may be used by the guarantor 1324 to generate a zero knowledge proof. Any other guarantor 1324 cannot access the insurance file generated by insurance document generation module 1302 for first guarantor 1324 without permission from first guarantor 1324. Any other guarantor 1324 cannot access the encryption key generated by insurance document encryption module 1306 for first guarantor 1324 without permission from first guarantor 1324. Without permission of the first guarantor 1324, no other guarantor 1324 may have access to the zero knowledge proof generated by the zero knowledge proof generation module 1348 for the first guarantor 1324.

In some implementations, the user interface module 1314 may provide an integrated user interface (e.g., in the form of a network port) to enable the applicant 1322, guarantor 1324, beneficiary 1326, and beneficiary agent 1342 to access the functionality of the various modules (e.g., 1302, 1304, 1306, 1308, 1310, 1312, 1316, 1344, 1346, and 1348) of the trusted insurance platform 1300. For example, applicant 1322 may use the set user interface to submit an application for insurance and track the status of the application, and/or invoke the insurance revocation handler module 1344 to facilitate revocation of insurance. The guarantor 1324 may use the integrated user interface to invoke the insurance document generation module 1302 to generate an insurance document, invoke the insurance document encryption module 1306 to generate ciphertext of the insurance document and generate an encryption key, invoke the zero-knowledge proof generation module 1348 to generate a zero-knowledge proof, invoke the insurance cross-chain processing module 1346 to facilitate interaction between two or more blockchain networks, or any combination thereof. Guarantor 1324 may use integrated user interface to invoke insurance issuance processing module 1308 to issue an insurance policy. The beneficiary agent 1342 may use the integrated user interface to invoke the insurance fulfillment processing module 1310 to process the withdrawal request and/or to invoke the insurance expiration processing module 1312 to confirm the expiration of the insurance.

Fig. 14a and 14b are diagrams illustrating an example of how an applicant, guarantor and beneficiary of a letter of credit use a blockchain-based trusted insurance platform 1300. Fig. 14a shows the relationship between applicant, guarantor and beneficiary. FIG. 14b illustrates the relationship between the blockchain-based trusted insurance platform 1300 and the applicant, guarantor and beneficiary. In this example, a snowboard manufacturer 1400 located in Berlington, Buddlef, USA developed a new type of snowboard that used a semiconductor chip manufactured by chip manufacturer 1402 in Guangdong Shenzhen, China. The skis may be used with ski analysis software developed by software developer 1404 in paris, france. The ski training center 1406, located in beijing, china, plans to purchase skis manufactured by the ski manufacturer 1400 and distribute them to ski teams for training in preparation for the 2022 year winter olympic games.

The snowboard manufacturer 1400 enters into a procurement agreement with the chip manufacturer 1402, where the snowboard manufacturer 1400 agrees to pay $ 100 million to the chip manufacturer 1402 within 30 days after delivery of 100,000 chips that may be mounted on a snowboard the snowboard manufacturer 1400 and the chip manufacturer 1402 have no previous relationship to each other, and the chip manufacturer 1402 is uncertain whether the snowboard manufacturer 1400 can be trusted to pay on time.

Snowboard manufacturer 1400 accesses trusted insurance platform 1300 according to blockchain-based letter of credit issuance process 700 of fig. 7 to obtain 100 ten thousand dollars of SB L c.sb L C from issuing bank 1408 (the U.S. bank in this example) is recorded in the blockchain (e.g., using steps equivalent or similar to step 718), and after receiving bank 1410 (the chinese worker bank) confirms acceptance of SB L C, the status of SB L C is updated to "issued" (e.g., using steps equivalent or similar to step) 722. for example, if receiving bank 1410 found a typing error in SB L C before receiving bank 1410 accepts SB L C, receiving bank 1410 may use trusted insurance platform 1300 to request a revision to SB L C using a process that includes steps equivalent or similar to steps 724-736.

After the chip manufacturer 1402 hands 100,000 chips to the snowboard manufacturer 1400, the snowboard manufacturer 1400 sends a payment of 100 dollars to the chip manufacturer 1402, using the trusted insurance platform 1300, the chip manufacturer 1402 notifies the collection bank 1410 about the full payment, the collection bank 1410 validates the payment and submits a validation to the issuing bank 1408 and the snowboard manufacturer 1400, and the validation of the full payment is stored in the blockchain (e.g., using steps equivalent or similar to

steps

1104 and 1106 in FIG. 11). the snowboard manufacturer 1400 uses the trusted insurance platform 1300 to submit a request to revoke SB L C using a process that includes steps equivalent or similar to steps 1108-1120, resulting in the status of SB L C being updated to "revoked" and recorded on the blockchain.

For example, instead of paying one million dollars at a time, the snowboard manufacturer 1400 may agree to pay the chip manufacturer 1402 in two phases.after the first predetermined milestone is reached, the snowboard manufacturer 1400 pays 50 million dollars to the chip manufacturer 1402.Using a process that includes steps equivalent or similar to steps 1002 through 1006 of FIG. 10, the chip manufacturer 1402 acknowledges receipt of the partial payment and stores the acknowledgement of the partial payment in the blockchain.after the partial payment is made, the snowboard manufacturer 1400 submits a revision to SB L C to reduce the wager amount from 100 million dollars to 50 million dollars, resulting in SB L C being revised and the revised SB L C being stored in the blockchain.

For example, the snowboard manufacturer 1400, software developer 1404, and ski training center 1406 make an agreement where (i) the snowboard manufacturer 1400 agrees to pay $ 20 ten thousand to the software developer 1404 within 30 days after delivery of a generic ski analysis package that can process data generated by a custom chip integrated into a snowboard, and (ii) the ski training center 1406 agrees to pay $ 10 ten thousand to the software developer 1404 within 30 days after delivery of a custom ski analysis package specifically configured for chinese skiers, plus 1 ten thousand dollars per month for a year, for software updates and services. Software developer 1404 has an account with a receiving bank 1412, which in this example is a free-country bank 1412. Ski training center 1406 has an account with issuing bank 1414, which in this example issuing bank 1414 is a chinese bank.

Snowboard manufacturer 1400 and ski training center 1406 access the trusted insurance platform 1300 to collectively obtain SB L C from issuing

banks

1408 and 1414 using a process similar to blockchain-based letter of credit issuance process 700 of FIG. 7. in this example, the total premium of SB L C is $ 42 million, with issuing bank 1408 (serving snowboard manufacturer 1400) vouching $ 20 million and issuing bank 1414 (serving ski training center 1406) vouching $ 20.

For example, issuing bank 1408 (servicing snowboard manufacturer 1400) and issuing bank 1414 (servicing snowboard training center 1406) are participant nodes of a first blockchain network that maintains a first blockchain.A receiving bank 1412 (servicing software developer 1404) is a participant node of a second blockchain network that maintains a second blockchain.Initially, after snowboard manufacturer 1400 and snowboard training center 1406 apply for SB L C, SB L C is recorded in the first blockchain.

After software developer 1404 has delivered the universal ski analysis package to ski manufacturer 1400 and ski manufacturer 1400 has paid $ 20 million to software developer 1404, ski manufacturer 1400 can request a revision to SB L C using a process that includes equivalent or similar steps to steps 1008 through 1036 of fig. 10 to reduce the wager amount from $ 42 million to $22 million and update the status of SB L C to confirm that software developer 1404 has received a payment of $ 20 million from ski manufacturer 1400.

After software developer 1404 delivers the customized ski analysis package to ski training center 1406 and ski training center 1406 pays $ 10 million to software developer 1404, ski training center 1406 may request a revision to SB L C using a process that includes steps equivalent or similar to steps 1008-1036 of fig. 10 to reduce the wager amount from $22 to $ 12 and update the status of SB L C to confirm that software developer 1404 has received a payment of $ 10 from ski training center 1406 after which SB L C may be revised using the process described above to reduce the wager amount each time ski training center 1406 makes a monthly payment of $ 1 for $ 1.twelve months, ski training center 1406 may request a revocation of SB L C using a process that includes steps equivalent or similar to steps 1108-1120 of fig. 11.

The example of fig. 14a and 14b shows how a blockchain based trusted insurance platform 1300 provides an integrated system that can be used by companies located in different countries of different continents to conveniently handle processes related to insurance such as credit or reserve credit to establish trust between parties and facilitate business transactions to facilitate business development anywhere.

Fig. 15 depicts an example of a process 1500 that may be performed in accordance with embodiments herein. For convenience, process 1500 will be described as being performed by a system of one or more computers located at one or more locations and suitably programmed according to the present disclosure. For example, a suitably programmed internal computer system, such as internal system 401 of FIG. 4, may perform process 1500.

At 1502, the computer system receives an application for an insurance policy made by at least a first insurer to a beneficiary from a computing device associated with an applicant, wherein the application includes information associated with an identity of the applicant, an identity of the beneficiary, and one or more predetermined conditions for executing the insurance policy.

At 1504, the computer system generates a digital version of the insurance based on information included in the application. At 1506, the block chain node encrypts the digital version to generate ciphertext of the insurance.

At 1508, the computer system generates one or more Zero Knowledge Proofs (ZKPs) relating to one or more values associated with the insurance. At 1510, the block chaining point sends the ciphertext of the insurance and the one or more zero knowledge proofs to the block chain network to store the ciphertext of the insurance on the block chain, wherein the ciphertext of the insurance is stored on the block chain by consensus of the block chain nodes after the one or more zero knowledge proofs are successfully verified by the block chaining point in the block chain network.

In some cases, the form of the insurance is SB L C. in some cases, the insurance specifies that the insurer should pay a predetermined amount to the beneficiary when one or more predetermined conditions for executing the insurance are met.

In some cases, the guarantor is an offshore bank that provides services to the applicant and the predetermined amount is paid to the beneficiary through an onshore bank that provides services to the beneficiary when one or more predetermined conditions are met.

In some cases, the application also includes information demonstrating the applicant's ability to pay a predetermined amount in the event of a breach of SB L C.

In some cases, the identity of the applicant includes one or more of the name, address, telephone number, email address, and type of service of the applicant. In some cases, the identity of the beneficiary includes one or more of the beneficiary's name, address, phone number, email address, and type of service.

In some cases, the one or more predetermined conditions include one or more of a default condition, a revision condition, a revocation condition, an effective date, and an expiration date. In some cases, at least one of the one or more zero-knowledge proofs is generated based on homomorphic encryption.

In some cases, the one or more zero knowledge proofs include a range proof and/or a zero test. In some cases, the encryption key used to encrypt the digital version is derived based on a linear secret sharing scheme.

In some cases, the insurance is made to the beneficiary by a first guarantor and a second guarantor, the insurance being in the form of SB L C, and the insurance specifies that the first guarantor and the second guarantor should pay the beneficiary a predetermined amount when one or more predetermined conditions for executing the insurance are met.

In some cases, the first guarantor is a first bank that services the applicant, the second guarantor is a second bank that services the applicant, and the application further includes information certifying that, in the event the applicant breaches SB L C, the applicant has sufficient funds in the first bank and the second bank to pay the predetermined amount.

In some cases, process 1500 further includes: the one or more zero knowledge proofs are verified, and after the one or more zero knowledge proofs are verified, consensus is performed based on the ciphertext of the insurance policy, and after the consensus is successfully performed, the ciphertext of the insurance policy is stored into a blockchain associated with the blockchain network.

In some cases, process 1500 further includes: receiving, at a first computing device, an application for an insurance policy made by an insurer to a beneficiary, wherein the application includes information associated with an identity of an applicant, an identity of the beneficiary, and one or more predetermined conditions under which the insurance policy is to be executed; sending the application to a second computing device associated with the guarantor; receiving, at a first computing device, a digital version of an application-generated insurance policy; encrypting the digital version to generate a ciphertext of the insurance; generating one or more zero-knowledge proofs relating to one or more values associated with the insurance policy; and sending the ciphertext and the one or more zero knowledge proofs to the blockchain network to store the ciphertext on the blockchain, wherein the ciphertext is stored on the blockchain by consensus of the blockchain nodes after the one or more zero knowledge proofs are successfully verified by the blockchain link points in the blockchain network.

Fig. 16 is a diagram of an example of modules of an apparatus 1600 according to embodiments herein. Apparatus 1600 may be an example of an embodiment of a computer system configured to process insurance policy information. The apparatus 1600 may correspond to the above-described embodiments, and the apparatus 1600 includes the following: a receiving module 1602 for receiving an application for an insurance policy made by at least a first insurer to a beneficiary from a computing device associated with an applicant, wherein the application includes information associated with an identity of the applicant, an identity of the beneficiary, and one or more predetermined conditions for executing the insurance policy; a generation module 1604 for generating a digital version of the insurance policy based on information included in the application; an encryption module 1606 for encrypting the digital version to generate a ciphertext of the insurance function; the generation module 1604 generates one or more zero knowledge proofs relating to one or more values associated with the insurance policy; a sending module 1608, configured to send the ciphertext of the insurance policy and the one or more zero knowledge proofs to the blockchain network to store the ciphertext of the insurance policy on the blockchain, wherein the ciphertext of the insurance policy is stored on the blockchain by consensus of the blockchain nodes after the one or more zero knowledge proofs are successfully verified by the blockchain nodes in the blockchain network.

In an alternative embodiment, the insurance is in the form of SB L C. in an alternative embodiment, the insurance specifies that the insurer should pay a predetermined amount to the beneficiary when one or more predetermined conditions for executing the insurance are met.

In an alternative embodiment, the guarantor is an offshore bank that provides services to the applicant and the beneficiary will be paid by an onshore bank that provides services to the beneficiary when the predetermined amount of money is met upon one or more predetermined conditions. In an alternative embodiment, the application also includes information specifying the identity of the bank at the bank.

In an alternative embodiment, the identity of the applicant includes one or more of the applicant's name, address, telephone number, email address and type of service.

In an alternative embodiment, the identity of the beneficiary includes one or more of the beneficiary's name, address, phone number, email address, and type of service. In an alternative embodiment, the one or more predetermined conditions include one or more of default conditions, revision conditions, revocation conditions, validation dates, and expiration dates.

In an alternative embodiment, the insurance is made to the beneficiary by a first guarantor and a second guarantor, the insurance being in the form of SB L C, and the insurance specifying that the first guarantor and the second guarantor should pay the beneficiary a predetermined amount upon satisfaction of one or more predetermined conditions for executing the insurance.

In an alternative embodiment, the first guarantor is a first bank that services the applicant, the second guarantor is a second bank that services the applicant, and the application further includes information certifying that in the event the applicant breaches SB L C, the applicant has sufficient funds in the first bank and the second bank to pay the predetermined amount.

In an alternative embodiment, apparatus 1600 further comprises: and the verification sub-module is used for verifying the one or more zero knowledge proofs, performing consensus based on the ciphertext of the insurance function after the one or more zero knowledge proofs are verified, and storing the ciphertext of the insurance function into the blockchain associated with the blockchain network after the consensus is successfully performed.

In an alternative embodiment, apparatus 1600 further comprises: receiving, at a first computing device, an application for an insurance policy made by an insurer to a beneficiary, wherein the application includes information associated with an identity of an applicant, an identity of the beneficiary, and one or more predetermined conditions under which the insurance policy is to be executed; sending the application to a second computing device associated with the guarantor; receiving, at a first computing device, a digital version of an application-generated insurance policy; encrypting the digital version to generate a ciphertext of the insurance; generating one or more zero-knowledge proofs relating to one or more values associated with the insurance policy; and sending the ciphertext and the one or more zero knowledge proofs to the blockchain network to store the ciphertext on the blockchain, wherein the ciphertext is stored on the blockchain by consensus of the blockchain nodes after the one or more zero knowledge proofs are successfully verified by the blockchain link points in the blockchain network.

Fig. 17 depicts a flowchart of another example of a process 1700 that may be performed in accordance with embodiments herein. For convenience, process 1700 will be described as being performed by a block-linked point, which may comprise a system of one or more computers located at one or more locations and suitably programmed according to the present disclosure. For example, a suitably programmed computer system, such as computer system 100 of FIG. 1, may perform process 1700.

At 1702, a block chaining point receives ciphertext of a digital document specifying an insurance from a first computing device associated with a first guarantor, wherein the insurance is made by the first guarantor to a beneficiary, and one or more zero knowledge proofs relating to one or more values associated with the insurance, and the digital document specifies one or more predetermined conditions for executing the insurance.

At 1704, the block link points verify that one or more zero knowledge proofs are correct. At 1706, after verifying that the one or more zero knowledge proofs are correct, the block link points store the ciphertext into the blockchain based on performing a consensus algorithm.

At 1708, the block link point receives a first message from a second computing device associated with the beneficiary or a representative of the beneficiary, the first message comprising the beneficiary's acceptance of the insurance. At 1710, the block link points update the status of the insurance to indicate that the beneficiary has accepted the insurance.

In some cases, the guarantor is an offshore bank that provides services to the applicant of the digital document, the representative of the beneficiary is an onshore bank that provides services to the beneficiary, and the predetermined amount is paid to the beneficiary through the onshore bank upon satisfaction of one or more predetermined conditions.

In some cases, the digital document also includes information specifying the identity of the bank at the bank. In some cases, the one or more predetermined conditions include one or more of a default condition, a revision condition, a revocation condition, an effective date, and an expiration date.

In some cases, at least one of the one or more zero-knowledge proofs is generated based on homomorphic encryption. In some cases, the one or more zero knowledge proofs include a range proof and/or a zero test.

In some cases, the insurance is made by the first guarantor and the second guarantor to the beneficiary, the insurance being in the form of SB L C, and the insurance specifying that the first guarantor and the second guarantor should pay the beneficiary a predetermined amount when one or more predetermined conditions for executing the insurance are met.

Fig. 18 is a diagram of another example of modules of an apparatus 1800 according to embodiments herein. Apparatus 1800 may be an example of an embodiment of a blockchain node. The apparatus 1800 may correspond to the embodiments described above, and the apparatus 1800 comprises the following: a receiving module 1802 for receiving ciphertext of a digital document specifying an insurance policy from a first computing device associated with a first guarantor, the insurance policy being made by the first guarantor to a beneficiary, and one or more zero knowledge proofs relating to one or more values associated with the insurance policy, the digital document specifying one or more predetermined conditions for executing the insurance policy; a verification module 1804 for verifying that the one or more zero knowledge proofs are correct; a storage module 1806, configured to store the ciphertext into the blockchain based on performing a consensus algorithm after verifying that the one or more zero-knowledge proofs are correct; the receiving module 1802 receiving a first message from a second computing device associated with a beneficiary or a representative of the beneficiary, the first message including the beneficiary's acceptance of the insurance; and an update module 1808 for updating the status of the insurance to indicate that the insurance has been accepted by the beneficiary.

In an alternative embodiment, the guarantor is an offshore bank that services the applicant of the digital document, the beneficiary is represented by an onshore bank that services the beneficiary, and the predetermined amount is paid to the beneficiary through the onshore bank upon satisfaction of one or more predetermined conditions.

In an alternative embodiment, the application also includes information specifying the identity of the bank at the bank. In an alternative embodiment, the one or more predetermined conditions include one or more of default conditions, revision conditions, revocation conditions, validation dates, and expiration dates.

In an alternative embodiment, at least one of the one or more zero knowledge proofs is generated based on homomorphic encryption. In alternative embodiments, the one or more zero knowledge proofs include a range proof and/or a zero test.

In an alternative embodiment, the insurance is made by the first guarantor and the second guarantor to the beneficiary, the insurance being in the form of SB L C, and the insurance specifying that the first guarantor and the second guarantor should pay the beneficiary a predetermined amount when one or more predetermined conditions for executing the insurance are met.

Fig. 19 is a flow diagram of yet another example of a process 1900 according to embodiments herein. For convenience, process 1900 will be described as being performed by a block-linked point comprising a system of one or more computers located at one or more locations and appropriately programmed according to the disclosure. For example, a suitably programmed computer system, such as computer system 100 of FIG. 1, can perform process 1900.

At 1902, a blockchain node receives ciphertext of a digital document specifying an insurance, and one or more zero knowledge proofs relating to one or more values associated with the insurance, wherein the insurance is made by at least a first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions for executing the insurance.

At 1904, the block link points verify one or more zero knowledge proofs. At 1906, upon successful verification of the one or more zero knowledge proofs, the block chaining point stores the ciphertext into the block chain based on executing the consensus algorithm.

At 1908, the block link point receives a withdrawal request for the insurance from a first computing device associated with the beneficiary or representative of the beneficiary. At 1910, the blockchain link point stores the withdrawal request into the blockchain based on executing the consensus algorithm.

At 1912, block link point communicates a first message regarding the withdrawal request to a second computing device associated with the first guarantor. At 1914, the block link point receives a second message from a second computing device associated with the first guarantor indicating that the first guarantor agrees to pay the beneficiary in accordance with the insurance policy.

At 1916, the blockchain link point updates the status of the deposit letter stored in the blockchain to indicate that the first guarantor has processed the withdrawal request for the deposit letter.

At 1918, the block link communicates a third message to the first computing device associated with the beneficiary or representative of the beneficiary, the third message indicating that the first guarantor agrees to pay the beneficiary in accordance with the insurance policy.

At 1920, the block link point receives a fourth message from the first computing device associated with the beneficiary or a representative of the beneficiary indicating that the beneficiary has received payment from the first guarantor.

At 1922, the blockchain link point updates the status of the insurance stored in the blockchain to indicate that the beneficiary has received payment for the insurance.

In some cases, the first guarantor is an offshore bank that provides services to an applicant of the digital document, the representative of the beneficiary is an onshore bank that provides services to the beneficiary, and the predetermined amount is paid to the beneficiary through the onshore bank when one or more predetermined conditions are met.

In an alternative embodiment, process 1900 includes receiving a ciphertext of a digital document specifying a insurance policy, and one or more zero knowledge proofs relating to one or more values associated with the insurance policy, wherein the insurance policy is made by at least a first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions for executing the insurance policy; verifying one or more zero knowledge proofs; after successful verification of one or more zero knowledge proofs, storing the ciphertext into a blockchain based on executing a consensus algorithm; receiving a withdrawal request for the insurance from a first computing device associated with the beneficiary or a representative of the beneficiary; storing the withdrawal request into a blockchain based on executing a consensus algorithm; communicating a first message regarding the withdrawal request to a second computing device associated with the first guarantor; receiving a second message from a second computing device associated with the first guarantor, wherein the second message includes a repudiation notification indicating that the first guarantor does not agree to pay the beneficiary according to the insurance policy; storing the declination notification in a blockchain based on executing a consensus algorithm; communicating a third message to the first computing device associated with the beneficiary or the representative of the beneficiary, wherein the third message comprises a repudiation notification; receiving a fourth message from the first computing device associated with the beneficiary or representative of the beneficiary indicating that the beneficiary or representative of the beneficiary has received the notice of declination, and updating a status of the insurance policy stored in the blockchain to indicate that the withdrawal request has ended.

Fig. 20 is a diagram of yet another example of modules of an apparatus 2000, according to embodiments herein. The apparatus 2000 may be an example of an embodiment of a blockchain. The apparatus 2000 may correspond to the above described embodiments, and the apparatus 2000 comprises the following: a receiving module 2002 for receiving a ciphertext of a digital document specifying a insurance policy, and one or more zero knowledge proofs relating to one or more values associated with the insurance policy, wherein the insurance policy is made by at least a first insurer to a beneficiary and the digital document specifies one or more predetermined conditions for executing the insurance policy; a verification module 2004 for verifying one or more zero knowledge proofs; a storage module 2006, configured to store the ciphertext into the block chain based on performing a consensus algorithm by the block link point after the one or more zero knowledge proofs are successfully verified; the receiving module 2002 receives a withdrawal request for the insurance from a first computing device associated with the beneficiary or a representative of the beneficiary; the storage module 2006 stores the withdrawal request into the blockchain based on executing the consensus algorithm; a delivery module 2008 for delivering a first message regarding the withdrawal request to a second computing device associated with the first guarantor; the receiving module 2002 receives a second message from a second computing device associated with the first guarantor, the second message indicating that the first guarantor agrees to pay the beneficiary according to the insurance policy; an update module 2010 for updating the status of the deposit letter stored in the blockchain to indicate that the first guarantor has processed a withdrawal request for the deposit letter; the transfer module 2008 transfers a third message to the first computing device associated with the beneficiary or representative of the beneficiary, the third message indicating that the first guarantor agrees to pay the beneficiary in accordance with the insurance policy; the receiving module 2002 receives a fourth message from the first computing device associated with the beneficiary or representative of the beneficiary, the fourth message indicating that the beneficiary has received payment from the first guarantor; and the update module 2010 updates the status of the insurance policy stored in the blockchain to indicate that the beneficiary has received payment for the insurance policy.

In an alternative embodiment, the first guarantor is an offshore bank that services an applicant of the digital document, the beneficiary representative is an onshore bank that services the beneficiary, and the predetermined amount is paid to the beneficiary through the onshore bank upon satisfaction of one or more predetermined conditions.

In an alternative embodiment, the digital document also includes information specifying the identity of the bank at the bank. In an alternative embodiment, the one or more predetermined conditions include one or more of default conditions, revision conditions, revocation conditions, validation dates, and expiration dates.

In an alternative embodiment, apparatus 2000 includes, a receiving module 2002 for receiving ciphertext of a digital document specifying a insurance policy, and one or more zero knowledge proofs relating to one or more values associated with the insurance policy, wherein the insurance policy is made by at least a first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions for executing the insurance policy; a verification module 2004 for verifying one or more zero knowledge proofs; a storage module 2006, configured to store the ciphertext into the blockchain based on performing a consensus algorithm after the one or more zero knowledge proofs are successfully verified; receiving a withdrawal request for the insurance from a first computing device associated with the beneficiary or a representative of the beneficiary; the storage module 2006 further stores the withdrawal request into a blockchain based on executing the consensus algorithm; a delivery module 2008 for delivering a first message regarding the withdrawal request to a second computing device associated with the first guarantor; the receiving module 2002 further receives a second message from a second computing device associated with the first guarantor, wherein the second message includes a repudiation notification indicating that the first guarantor does not agree to pay the beneficiary according to the insurance policy; the storage module 2006 further stores the declination notification in a blockchain based on executing the consensus algorithm; the delivery module 2008 further delivers a third message to the first computing device associated with the beneficiary or representative of the beneficiary, wherein the third message includes a repudiation notification; the receiving module 2002 further receives a fourth message from the first computing device associated with the beneficiary or representative of the beneficiary indicating that the beneficiary or representative of the beneficiary has received the notice of declination, and an updating module 2010 to update the status of the insurance policy stored in the blockchain to indicate that the withdrawal request has ended.

Fig. 21 is a flow diagram of yet another example of a process 2100 according to embodiments herein. For convenience, process 2100 will be described as being performed by a block-linked point comprising a system of one or more computers located at one or more locations and appropriately programmed according to the disclosure. For example, a suitably programmed computer system, such as computer system 100 of FIG. 1, can perform process 2100.

At 2102, a block chaining point receives a ciphertext of a digital document specifying an insurance, and one or more zero knowledge proofs relating to one or more values associated with the insurance, wherein the insurance is made by at least a first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions for executing the insurance.

At 2104, the block chain link points verify one or more zero knowledge proofs. At 2106, upon successful verification of the one or more zero knowledge proofs, the block chain node stores the ciphertext into the blockchain based on executing the consensus algorithm. At 2108, the block link point receives a first message from a first computing device associated with the beneficiary or representative of the beneficiary, the first message indicating that there are no unpaid claims for the insurance.

At 2110, the block link point sends a second message to a second computing device associated with the first guarantor confirming that the first guarantor is decommissioned from payment under the insurance policy. At 2112, the blockchain nexus receives a third message from the second computing device associated with the first guarantor requesting that the status of the insurance change to have expired.

At 2114, the blockchain link point updates the status of the insurance stored in the blockchain to indicate that the insurance has expired.

In some cases, the form of the insurance is SB L C. in some cases, the insurance specifies that at least a first guarantor should pay a predetermined amount to a beneficiary when one or more predetermined conditions for executing the insurance are met.

In some cases, the first guarantor is an offshore bank that provides services to an applicant of the digital document, the representative of the beneficiary is an onshore bank that provides services to the beneficiary, and the predetermined amount is paid to the beneficiary through the onshore bank when one or more predetermined conditions are met. In some cases, the digital document also includes information specifying the identity of the bank at the bank.

In some cases, the one or more zero knowledge proofs include a range proof and/or a zero test. In some cases, the ciphertext is encrypted using an encryption key derived based on a linear secret sharing scheme.

In some cases, the consensus algorithm is based on one of Pow, PoS, and PBFT. In some cases, process 2100 further includes: prior to receiving the first message, receiving a fourth message from the first computing device associated with the beneficiary or representative of the beneficiary, wherein the fourth message comprises a request to extend the effective life of the insurance function; and storing the request for extending the life of the insurance function in the block chain.

Fig. 22 is a diagram of yet another example of modules of an apparatus 2200 according to embodiments herein. Apparatus 2200 may be an example of an embodiment of a blockchain node. The apparatus 2200 may correspond to the above-described embodiment, and the apparatus 2200 includes the following: a receiving module 2202 for receiving ciphertext of a digital document specifying a insurance policy, and one or more zero knowledge proofs relating to one or more values associated with the insurance policy, wherein the insurance policy is made by at least a first insurer to a beneficiary and the digital document specifies one or more predetermined conditions for executing the insurance policy; a validation module 2204 to validate one or more zero knowledge proofs; a storage module 2206, configured to store the ciphertext into the blockchain based on executing the consensus algorithm after the one or more zero-knowledge proofs are successfully verified; the receiving module 2202 receives a first message from a first computing device associated with a beneficiary or a representative of the beneficiary, the first message indicating that there are no unpaid claims for the insurance premium; a sending module 2208 for sending a second message to a second computing device associated with the first guarantor to confirm that the first guarantor is decommissioned from payment obligations under the insurance coverage; the receiving module 2202 receives a third message from the second computing device associated with the first guarantor requesting that the status of the insurance change to be expired; and an update module 2210 for updating a state of the insurance policy stored in the blockchain to indicate that the insurance policy has expired.

In an alternative embodiment, the insurance is in the form of SB L C. in an alternative embodiment, the insurance specifies that at least a first guarantor should pay a predetermined amount to a beneficiary when one or more predetermined conditions for executing the insurance are met.

In an alternative embodiment, the consensus algorithm is based on one of Pow, PoS, and PBFT. In an alternative embodiment, the apparatus 2200 further comprises a receiving sub-module for receiving a fourth message from the first computing device associated with the beneficiary or representative of the beneficiary prior to receiving the first message, wherein the fourth message comprises a request to extend the life of the insurance policy; and the storage submodule is used for storing the request for prolonging the effective period of the insurance function in the block chain.

Fig. 23 is a flow diagram of yet another example of a process 2200 according to embodiments herein. For convenience, process 2300 will be described as being performed by a block-link point comprising a system of one or more computers located at one or more locations and suitably programmed according to the disclosure. For example, a suitably programmed computer system, such as computer system 100 of FIG. 1, can perform process 2300.

At 2302, a block chaining point receives a first ciphertext of a first digital document specifying an insurance from a first computing device associated with at least a first guarantor, wherein the insurance is made by the at least first guarantor to a beneficiary, and one or more zero knowledge proofs relating to one or more values associated with the insurance, and the digital document specifies one or more predetermined conditions for executing the insurance.

At 2304, the block link points verify that one or more zero knowledge proofs are correct. At 2306, after verifying that one or more zero knowledge proofs are correct, the block link points store the first ciphertext into the block chain based on performing a consensus algorithm.

At 2308, a block link point receives a first message from a second computing device associated with a beneficiary or representative of the beneficiary, the first message including a request to modify an insurance policy. At 2310, the block chaining point sends a second message to the first computing device relating to the request to modify the insurance policy.

At 2312, the blockchain node receives, from the first computing device, a second ciphertext of a second digital document specifying a insurance policy, the second digital document representing a modified version of the first digital document, wherein the modification is based on the request.

In some cases, process 2300 further includes: based on executing the consensus algorithm, storing the second ciphertext to the block chain; receiving, from the second computing device, a third message indicating acceptance of the insurance policy specified in the second digital document; the second ciphertext is modified to update the state of the insurance policy to indicate that the beneficiary has accepted the insurance policy.

In some cases, the request to modify the deposit letter is a request to modify the predetermined amount to a reduced amount equal to the predetermined amount minus a payment amount paid to the beneficiary, and the modified version of the first digital document includes the reduced amount.

In some cases, the first message further includes a zero knowledge proof associated with the reduced amount of money, and the storing of the second ciphertext is performed in response to successfully verifying the zero knowledge proof included in the first message.

In some cases, the guarantor is an offshore bank that provides services to the applicant of the first digital document, and the predetermined amount is paid to the beneficiary through an onshore bank that provides services to the beneficiary when one or more predetermined conditions are met.

In some cases, the one or more zero knowledge proofs include a range proof and/or a zero test. In some cases, the encryption key used to encrypt the digital document is derived based on a linear secret sharing scheme.

Fig. 24 is a diagram of yet another example of modules of device 2400 according to an embodiment herein. Apparatus 2400 may be an example of an embodiment of a blockchain node. The apparatus 2400 may correspond to the above-described embodiment, and the apparatus 2400 includes the following: a receiving module 2402 for receiving a first ciphertext of a first digital document specifying an insurance from a first computing device associated with at least a first guarantor, and one or more zero knowledge proofs relating to one or more values associated with the insurance, wherein the insurance is made by the at least first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions for executing the insurance; a verification module 2404 for verifying that the one or more zero knowledge proofs are correct; a storage module 2406, configured to store the first ciphertext into the blockchain based on performing a consensus algorithm after verifying that the one or more zero knowledge proofs are correct; the receiving module 2402 further receives a first message from a second computing device associated with the beneficiary or representative of the beneficiary, the first message comprising a request to modify the insurance policy; a sending module 2408 for sending a second message to the first computing device relating to the request to modify the insurance policy; the receiving module 2402 further receives, from the first computing device, a second ciphertext of a second digital document that specifies a insurance envelope, the second digital document representing a modified version of the first digital document, wherein the modification is based on the request.

In an alternative embodiment, the apparatus 2400 further includes the storing module 2406 storing the second ciphertext to the blockchain based on performing the consensus algorithm; the receiving module 2402 receives a third message from the second computing device indicating acceptance of the insurance policy specified in the second digital document; and modifying the second ciphertext to update a state of the insurance policy to indicate that the beneficiary has accepted the insurance policy.

In an alternative embodiment, the request to modify the deposit is a request to modify the predetermined amount to a reduced amount equal to the predetermined amount minus a payment amount paid to the beneficiary, and the modified version of the first digital document includes the reduced amount.

In an alternative embodiment, the first message further includes a zero knowledge proof associated with the reduced amount of money, and the storing of the second ciphertext is performed in response to successfully verifying the zero knowledge proof included in the first message.

In an alternative embodiment, the guarantor is an offshore bank that provides services to the applicant of the first digital document, and the predetermined amount is paid to the beneficiary through an onshore bank that provides services to the beneficiary when one or more predetermined conditions are met.

In an alternative embodiment, the one or more predetermined conditions include one or more of default conditions, revision conditions, revocation conditions, validation dates, and expiration dates. In an alternative embodiment, at least one of the one or more zero knowledge proofs is generated based on homomorphic encryption.

In alternative embodiments, the one or more zero knowledge proofs include a range proof and/or a zero test. In an alternative embodiment, the encryption key used to encrypt the digital document is derived based on a linear secret sharing scheme.

In an alternative embodiment, the insurance is made to the beneficiary by a first guarantor and a second guarantor, the insurance being in the form of SB L C, and the insurance specifies that the first guarantor and the second guarantor should pay the beneficiary a predetermined amount upon satisfaction of one or more predetermined conditions for executing the insurance.

Fig. 25 is a flow diagram of yet another example of an apparatus 2500 according to embodiments herein. For convenience, process 2500 will be described as being performed by a block-linked point comprising a system of one or more computers located at one or more locations and appropriately programmed according to the disclosure. For example, a suitably programmed computer system, such as computer system 100 of FIG. 1, may perform process 2500.

At 2502, the block chaining point receives ciphertext of a digital document of a specified insurance from a first computing device associated with at least a first guarantor, wherein the insurance is made by the at least first guarantor to a beneficiary, and one or more zero knowledge proofs relating to one or more values associated with the insurance, and wherein the digital document specifies one or more predetermined conditions for executing the insurance.

At 2504, the block link points verify that one or more zero knowledge proofs are correct. At 2506, after verifying that the one or more zero knowledge proofs are correct, the block chaining point stores the first ciphertext into the block chain based on performing a consensus algorithm.

At 2508, a block chain node receives a first message from a first computing device associated with at least a first guarantor, the first message comprising a request to revoke the insurance. At 2510, the blockchain link point stores the request to undo the guarantee in the blockchain.

At 2512, the block link point sends a second message to a second computing device associated with the beneficiary or representative of the beneficiary, wherein the second message comprises a request to revoke the insurance policy.

At 2514, the block link point receives a third message from the second computing device associated with the beneficiary or representative of the beneficiary, wherein the third message includes confirmation that the beneficiary accepted the revocation insurance. At 2516, the block link points update the status of the insurance stored in the block chain to indicate that the insurance has been revoked.

In some cases, the first guarantor is an offshore bank that provides services to the applicant of the insurance and the predetermined amount is paid to the beneficiary through an onshore bank that provides services to the beneficiary when one or more predetermined conditions are met.

In some cases, a guarantee is made by the first guarantor and the second guarantor to the beneficiary, the guarantee being in the form of SB L C, and the guarantee specifying that the first guarantor and the second guarantor should pay the beneficiary a predetermined amount when one or more predetermined conditions for executing the guarantee are met.

Fig. 26 is a diagram of yet another example of modules of an apparatus 2600 in accordance with an embodiment herein. The apparatus 2600 may be an example of an embodiment of a block chain. The apparatus 2600 may correspond to the above-described embodiment, and the apparatus 2600 comprises the following: a receiving module 2602 for receiving ciphertext of a digital document specifying an insurance policy from a first computing device associated with at least a first guarantor, wherein the insurance policy was made by the at least first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions for executing the insurance policy, and one or more zero knowledge proofs relating to one or more values associated with the insurance policy; a verification module 2604 to verify that one or more zero knowledge proofs are correct; a storage module 2606, configured to store the first ciphertext into the blockchain based on performing a consensus algorithm after verifying that the one or more zero knowledge proofs are correct; the receiving module 2602 receives a first message from a first computing device associated with at least a first guarantor, the first message comprising a request to revoke the insurance policy; storage module 2606 stores the request to revoke the guarantee in the blockchain; a sending module 2608 for sending a second message to a second computing device associated with the beneficiary or representative of the beneficiary, wherein the second message comprises a request to revoke the insurance policy; the receiving module 2602 receives a third message from the second computing device associated with the beneficiary or representative of the beneficiary, wherein the third message comprises confirmation that the beneficiary accepted the revocation insurance policy; an update module 2610 is used to update the state of the insurance policy stored in the blockchain to indicate that the insurance policy has been revoked.

In an alternative embodiment, the first guarantor is an offshore bank that provides services to the applicant of the insurance and the predetermined amount is paid to the beneficiary through an onshore bank that provides services to the beneficiary when one or more predetermined conditions are met.

In an alternative embodiment, the insurance policy is made by the first guarantor and the second guarantor to the beneficiary, the insurance policy being in the form of SB L C, and the insurance policy specifying that the first guarantor and the second guarantor should pay the beneficiary a predetermined amount upon satisfaction of one or more predetermined conditions for executing the insurance policy.

Fig. 27 is a flow diagram of yet another example of modules of a device 2700 according to embodiments herein. For convenience, process 2700 will be described as being performed by a block chain node comprising a system of one or more computers located at one or more locations and appropriately programmed according to the disclosure. For example, process 2700 can be performed by a suitably programmed computer system, such as computer system 100 of FIG. 1.

At 2702, a blockchain link point in the first blockchain network receives a cross-link request for relaying a ciphertext of a digital document to the second blockchain network, wherein the cross-link request is sent from a first computing device associated with a first guarantor, the digital document specifies an insurance from the first guarantor and one or more predetermined conditions for performing the insurance, and the insurance is made by the first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions for performing the insurance.

At 2704, the blockchain nexus stores the cross-chain request and the ciphertext into a first blockchain associated with the first blockchain network based on executing the consensus algorithm. At 2706, the blockchain node receives a message from the second computing device to relay information between the first blockchain network and the second blockchain network, the message including an acknowledgement that the insurance was accepted by the beneficiary and stored on the second blockchain associated with the second blockchain network. At 2708, the block link point updates the status of the insurance to indicate that the insurance has been invalidated on the first block chain.

In some cases, process 2700 further includes: receiving, by a blockchain node, one or more zero knowledge proofs associated with ciphertext of a digital document, wherein the one or more zero knowledge proofs relate to one or more values associated with a insurance policy; verifying that the one or more zero knowledge proofs are correct prior to storing the ciphertext into the first blockchain associated with the first blockchain network.

In some cases, the second computing device is at least one of (i) a blockchain node in the first blockchain network and the second blockchain network, or (ii) a blockchain node in the third blockchain network.

In some cases, the second computing device is a trusted device that supports a trusted execution environment or secure multi-party computing. In some cases, updating the state of the insurance policy is performed in response to receiving a request from the first computing device to invalidate the insurance policy.

In some cases, the guarantor is an offshore bank that provides services to the applicant, the beneficiary is represented by an onshore bank that provides services to the beneficiary, and the predetermined amount is paid to the beneficiary through the onshore bank upon satisfaction of one or more predetermined conditions.

In some cases, the one or more predetermined conditions include one or more of a default condition, a revision condition, a revocation condition, an effective date, and an expiration date. In some cases, the one or more zero knowledge proofs include a range proof and/or a zero test, and at least one of the one or more zero knowledge proofs is generated based on homomorphic cryptography. In some cases, the ciphertext is encrypted using an encryption key derived based on a linear secret sharing scheme.

Fig. 28 is a diagram of yet another example of modules of an apparatus 2800 according to embodiments herein. Apparatus 2800 may be an example of an embodiment of a blockchain. Apparatus 2800 may correspond to embodiments described above, apparatus 2800 including the following: a receiving module 2802 for receiving, by a blockchain node in a first blockchain network, a cross-link request for relaying a ciphertext of a digital document to a second blockchain network, wherein the cross-link request is sent from a first computing device associated with a first guarantor, the digital document specifies an insurance from the first guarantor and one or more predetermined conditions for performing the insurance, and the insurance is made by the first guarantor to a beneficiary, and the digital document specifies one or more predetermined conditions for performing the insurance; a storage module 2804 for storing the cross-chain request and the ciphertext into a first blockchain associated with a first blockchain network based on executing a consensus algorithm; a receiving module 2802 that receives a message from a second computing device to relay information between the first blockchain network and the second blockchain network, the message including an acknowledgement that the insurance policy was accepted by the beneficiary and stored on a second blockchain associated with the second blockchain network; and an update module 2806 for updating a state of the insurance policy to indicate that the insurance policy has been invalidated on the first blockchain.

In an alternative embodiment, the apparatus 2800 further comprises a receiving submodule for receiving, by the blockchain node, one or more zero knowledge proofs associated with the ciphertext of the digital document, wherein the one or more zero knowledge proofs relate to one or more values associated with the insurance policy; and a verification sub-module to verify that the one or more zero knowledge proofs are correct prior to storing the ciphertext into the first blockchain associated with the first blockchain network.

In an alternative embodiment, the second computing device is at least one of (i) a blockchain node in the first blockchain network and the second blockchain network, or (ii) a blockchain node in the third blockchain network.

In an alternative embodiment, the second computing device is a trusted device that supports a trusted execution environment or secure multi-party computing. In an alternative embodiment, updating the state of the insurance policy is performed in response to receiving a request from the first computing device to invalidate the insurance policy.

In an alternative embodiment, the guarantor is an offshore bank that provides services to the applicant, the beneficiary's representative is an onshore bank that provides services to the beneficiary, and the predetermined amount is paid to the beneficiary through the onshore bank upon satisfaction of one or more predetermined conditions.

In an alternative embodiment, the one or more predetermined conditions include one or more of default conditions, revision conditions, revocation conditions, validation dates, and expiration dates. In an alternative embodiment, the one or more zero knowledge proofs include a range proof and/or a zero test, and at least one of the one or more zero knowledge proofs is generated based on homomorphic cryptography. In an alternative embodiment, the ciphertext is encrypted using an encryption key derived based on a linear secret sharing scheme.

The systems, apparatuses, modules or units shown in the foregoing embodiments may be implemented by using a computer chip or entity, or may be implemented by using an article having a specific function. Typical embodiment devices are computers, which may be personal computers, laptop computers, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email messaging devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

For example processing of the functions and actions of each module in the device, reference may be made to example processing of the corresponding steps in the previous method. Details are omitted here for simplicity.

Since the device implementation substantially corresponds to the method implementation, reference may be made to the relevant description in the method implementation for the relevant components. The previously described device implementations are merely examples. Modules described as separate parts may or may not be physically separate, and parts shown as modules may or may not be physical modules, may be located in one location, or may be distributed over multiple network modules. Some or all of the modules may be selected based on actual needs to achieve the goals of the present solution. Those of ordinary skill in the art will understand and appreciate the embodiments of the present application without undue experimentation.

Referring again to fig. 16, 18, 20, 22, 24, 26 and 28, these may be interpreted as showing the internal functional modules and structures of the computer system or block link points. The execution subject may be essentially an electronic device, and the electronic device includes the following: one or more processors; and one or more computer-readable memories configured to store executable instructions for the one or more processors. In some embodiments, one or more computer-readable memories are coupled to one or more processors and have stored thereon programming instructions that are executable by the one or more processors to perform algorithms, methods, functions, processes, procedures, and programs as described herein. Also provided herein are one or more non-transitory computer-readable storage media coupled to one or more processors and having instructions stored thereon that, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein.

Also provided herein are systems for implementing the methods provided herein. The system includes one or more processors, and a computer-readable storage medium coupled to the one or more processors and having instructions stored thereon that, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein.

Implementations of the subject matter, acts, and operations described herein may be implemented in digital electronic circuitry, tangibly embodied computer software or firmware, computer hardware, including the structures disclosed herein and structural equivalents thereof, or combinations of one or more of them. Implementations of the subject matter described herein may be implemented as one or more computer programs, e.g., one or more modules of computer program instructions encoded on a computer program carrier for execution by, or to control the operation of, data processing apparatus. For example, a computer program carrier may include one or more computer-readable storage media having instructions encoded or stored thereon. The carrier may be a tangible, non-transitory computer-readable medium such as a magnetic, magneto-optical disk or optical disk, a solid state drive, Random Access Memory (RAM), Read Only Memory (ROM), or other type of medium. Alternatively or additionally, the carrier may be an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by the data processing apparatus. The computer storage medium may be, or may be in part be, a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them. Computer storage media is not a propagated signal.

A computer program, which may also be referred to or described as a program, software application, app, module, software module, engine, script, or code, may be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; it can be deployed in any form, including as a stand-alone program or as a module, component, engine, subroutine, or other unit suitable for execution in a computing environment, which may include one or more computers at one or more locations interconnected by a data communications network.

A computer program may, but need not, correspond to a file in a file system. The computer program may be stored in: a portion of a file that holds other programs or data, e.g., one or more scripts stored in a markup language document; in a single file dedicated to the program in question; or multiple coordinated files, such as files that store one or more modules, sub programs, or portions of code.

A processor for executing a computer program comprising: e.g., both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions of a computer program for execution and data from a non-transitory computer-readable medium coupled to the processor.

The term "data processing apparatus" includes all kinds of apparatus, devices and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The data processing device may comprise dedicated logic circuitry, e.g., an FPGA (field programmable gate array), an ASIC (application specific integrated circuit) or a GPU (graphics processing unit). In addition to hardware, the apparatus can include code that creates an execution environment for the computer program, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

The processes and logic flows described herein can be performed by one or more computers or processors executing one or more computer programs to perform operations by operating on input data and generating output. The processes and logic flows can also be performed by, and in combination with, special purpose logic circuitry, e.g., an FPGA, an ASIC, or a GPU.

A computer suitable for executing a computer program may be based on a general and/or special purpose microprocessor, or any other kind of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory and/or a random access memory. Elements of a computer may include a central processing unit for executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory can be supplemented by, or integrated in, special purpose logic circuitry.

Typically, a computer will also include or be operatively coupled to one or more storage devices to receive data from, and to transfer data to, the one or more storage devices. The mass storage device may be, for example, a magnetic, magneto-optical disk or optical disk, a solid state drive, or any other type of non-transitory computer readable medium. However, a computer need not have such a device. Thus, a computer may be coupled to one or more mass storage devices, e.g., local and/or remote to one or more memories. For example, the computer may include one or more local memories as an integral part of the computer, or the computer may be coupled to one or more remote memories in a cloud network. Furthermore, the computer may be embedded in another device, e.g., a mobile telephone, a Personal Digital Assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device, e.g., a Universal Serial Bus (USB) flash drive, to name a few.

The components may be "coupled" to each other by connecting communications with each other, either directly or via one or more intermediaries, such as electrical or optical connections if one of the components is integrated into another, the components may also be "coupled" to each other, for example, a mass storage component integrated into a processor (e.g., a L cache component) is "coupled" to the processor.

In order to provide for interaction with a user, embodiments of the subject matter described herein may be implemented or configured on a computer in communication with the computer, the computer having a display device, e.g., an L CD (liquid crystal display) monitor, for displaying information to the user and an input device through which the user may provide input to the computer, e.g., a keyboard and a pointing device such as a mouse, trackball, or touchpad.

The term "configured" is used herein in relation to systems, devices, and computer program components. For a system of one or more computers configured to perform particular operations or actions, it is meant that the system has installed thereon software, firmware, hardware, or a combination thereof that, when executed, causes the system to perform the operations or actions. For one or more computer programs configured to perform specific operations or actions, it is meant that the one or more programs include instructions, which when executed by a data processing apparatus, cause the apparatus to perform the operations or actions. By dedicated logic circuitry configured to perform a particular operation or action is meant that the circuitry has electronic logic to perform the operation or action.

Although this document contains many specific implementation details, these should not be construed as limitations on the scope of the claims, which are defined by the claims themselves, but rather as descriptions of specific features of particular embodiments. Various features that are described in the context of a single embodiment herein can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings and recited in the claims in a particular order, this should not be understood as: it may be desirable to perform the operations in the particular order shown, or in sequence, or to perform all of the operations shown, in order to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Moreover, the division of the various system modules and components in the embodiments described above should not be understood as requiring such division in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Specific embodiments of the subject matter have been described. Other implementations are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not require the particular order shown, or sequence, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous.

Claims

1. A computer-implemented method performed by a block link point in a block chain network, comprising:

receiving a first ciphertext of a first digital document specifying a insurance from a first computing device associated with at least a first guarantor, and one or more zero knowledge proofs ZKP relating to one or more values associated with the insurance, wherein the insurance is made by the at least first guarantor to a beneficiary, and the first digital document specifies one or more predetermined conditions under which the insurance is performed;

verifying that the one or more zero knowledge proofs are correct;

after verifying that the one or more zero knowledge proofs are correct, storing the first ciphertext into a blockchain based on executing a consensus algorithm;

receiving a first message from a second computing device associated with a beneficiary or a representative of the beneficiary, the first message comprising a request to modify the insurance policy;

sending a second message to the first computing device relating to the request to modify the insurance policy; and

receiving, from the first computing device, a second ciphertext of a second digital document that specifies the insurance, the second digital document representing a modified version of the first digital document, wherein the modification is based on the request.

2. The method of claim 1, further comprising:

based on executing the consensus algorithm, storing the second ciphertext into the blockchain;

receiving, from the second computing device, a third message indicating acceptance of the insurance policy specified in the second digital document; and

modifying the second ciphertext to update a state of the insurance policy to indicate that the beneficiary has accepted the insurance policy.

3. A method according to any preceding claim, wherein the letter of guarantee is in the form of a spare letter of credit SB L C.

4. A method according to claim 3 wherein said insurance policy specifies that said at least first guarantor should pay a predetermined amount to said beneficiary when said one or more predetermined conditions for executing said insurance policy are met.

5. The method of claim 4 wherein the request to modify the letter of guarantee is a request to modify the predetermined amount to a reduced amount, the reduced amount being equal to the predetermined amount minus a payment amount paid to the beneficiary, and the modified version of the first digital document includes the reduced amount.

6. The method of claim 5, wherein the first message further includes a zero knowledge proof associated with the reduced amount of money, and the storing of the second ciphertext is performed in response to successfully verifying the zero knowledge proof included in the first message.

7. A method according to any preceding claim wherein the first guarantor is an offshore bank that services an applicant of the first digital document and the predetermined amount is paid to the beneficiary through an onshore bank that services the beneficiary when the one or more predetermined conditions are met.

8. A method as claimed in any preceding claim, wherein the one or more predetermined conditions comprise one or more of a default condition, a revision condition, a revocation condition, an expiry date and an effect date.

9. The method of any preceding claim, wherein at least one of the one or more zero-knowledge proofs is generated based on homomorphic cryptography.

10. The method of any preceding claim, wherein the one or more zero knowledge proofs comprise a range proof and/or a zero test.

11. The method of any preceding claim, wherein an encryption key used to encrypt the digital document is derived based on a linear secret sharing scheme.

12. A method according to claim 1 wherein said insurance is made to said beneficiary by said first and second guarantors in the form of an alternate letter of credit SB L C, and said insurance specifies that said first and second guarantors should pay a predetermined amount to said beneficiary upon satisfaction of said one or more predetermined conditions for executing said insurance.

13. A system for processing blockchain-based insurance information, comprising:

one or more processors; and

one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform the method of any of claims 1-12.

14. An apparatus for processing blockchain-based insurance information, the apparatus comprising a plurality of modules for performing the method of any of claims 1 to 12.