Method and apparatus for managing a standby letter of credit

Abstract

Disclosed herein are methods, devices, and apparatus for managing a standby letter of credit (SBLC), including a computer program stored on a computer-readable medium. The methods include receiving a first transaction from a first user, the first transaction comprising a first certificate and a first standby letter of credit promise; in response to determining that the first certificate is acceptable, recording the first standby letter of credit promise; receiving a second transaction from a second user, the second transaction comprising the first standby letter of credit token, a second certificate, a second standby letter of credit promise generated based on the second standby letter of credit token, and a first loan promise generated based on a first loan token; and in response to determining that the first standby letter of credit token is valid and the second certificate is acceptable, recording the second standby letter of credit promise and the first loan promise record and invalidating the first standby letter of credit token.

Description

Technical Field

[0001] This document relates generally to computer technology and, more particularly, to methods and apparatus for managing standby letters of credit. Background Art

[0002] A standby letter of credit (SBLC) is typically a document that guarantees a bank's payments on behalf of the bank's client. SBLCs are often used to facilitate transactions, including, for example, international transactions. In a typical use case, for example, a first client with a deposit account at a first bank may agree to act as guarantor for a loan that a second client wishes to take out from the second bank. For the second bank to accept the first client as a guarantor, the second bank may require the first bank to issue an SBLC. The SBLC is used to guarantee that the first bank will pay the second bank if the second client defaults on the loan. If the second client defaults, the first bank may pay the second bank and recover its costs by charging the first client's deposit account maintained by the first bank. In this example, the first bank may be referred to as the issuing bank, the second bank may be referred to as the beneficiary bank, the first client may be referred to as the principal, and the second client may be referred to as the borrower.

[0003] Due to the importance of SBLCs in facilitating certain types of transactions, parties involved in such transactions may have an incentive to record SBLCs in a blockchain system. Blockchain systems, also known as distributed ledger systems (DLSs) or consensus systems, enable participating entities to store data securely and immutably. Blockchain systems can include any DLS, without reference to any specific use case, and can be used in public, private, and consortium blockchain networks. Public blockchain networks are open to all entities to use the system and participate in the consensus process. Private blockchain networks are intended for specific entities, with centralized control over read and write permissions. Consortium blockchain networks are intended for a select group of entities, which control the consensus process and include an access control layer.

[0004] While recording the SBLC in a blockchain system can help prevent tampering and manipulation by malicious parties, doing so can also expose the information contained in the SBLC to unauthorized parties. Because the SBLC may contain sensitive information, including, for example, the identity of the issuing bank, the beneficiary bank, the parties involved, the borrower, the maximum amount the borrower is allowed to borrow, and the types of loans the borrower is allowed to arrange, recording the SBLC in a blockchain system may compromise the privacy of the parties associated with the SBLC. Summary of the Invention

[0005] In one aspect, a computer-implemented method for managing a standby letter of credit (SBLC) includes: receiving a first transaction from a first user, the first transaction comprising a first standby letter of credit commitment and a first attestation certifying that the first user is the issuer of the standby letter of credit, the first standby letter of credit commitment being generated based on a first standby letter of credit token; in response to determining that the first attestation is acceptable, recording the first standby letter of credit commitment in a standby letter of credit commitment pool; receiving a second transaction from a second user, the second transaction comprising the first standby letter of credit token, the second standby letter of credit commitment, a first loan commitment, and a second attestation certifying that the second user has issued a loan secured by the standby letter of credit, the second standby letter of credit commitment being generated based on a second standby letter of credit token, the first loan commitment being generated based on the first loan token; and in response to determining that the first standby letter of credit token is valid and the second attestation is acceptable, recording the second standby letter of credit commitment in the standby letter of credit commitment pool, recording the first loan commitment in a loan commitment pool, and invalidating the first standby letter of credit token.

[0006] In another aspect, an apparatus for managing an SBLC includes: one or more processors; and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon, the instructions executable by the one or more processors to: receive a first transaction from a first user, the first transaction including a first standby letter of credit offer and a first certification verifying that the first user is the issuer of the standby letter of credit, the first standby letter of credit offer being generated based on a first standby letter of credit token; in response to determining that the first certification is acceptable, record the first standby letter of credit offer in a standby letter of credit offer pool; receive a second transaction from a second user, the second transaction including the first standby letter of credit token, the second standby letter of credit offer, a first loan offer, and a second certification verifying that the second user has issued a loan secured by the standby letter of credit, the second standby letter of credit offer being generated based on a second standby letter of credit token, the first loan offer being generated based on the first loan token; and in response to determining that the first standby letter of credit token is valid and the second certification is acceptable, record the second standby letter of credit offer in the standby letter of credit offer pool, record the first loan offer in a loan offer pool, and invalidate the first standby letter of credit token.

[0007] In another aspect, a non-transitory computer-readable medium has instructions stored therein that, when executed by a processor of a device, cause the device to perform a method for managing an SBLC. The method includes: receiving a first transaction from a first user, the first transaction comprising a first standby letter of credit offer and a first certification verifying that the first user is the issuer of the standby letter of credit, the first standby letter of credit offer being generated based on a first standby letter of credit token; in response to determining that the first certification is acceptable, recording the first standby letter of credit offer in a standby letter of credit offer pool; receiving a second transaction from a second user, the second transaction comprising the first standby letter of credit token, the second standby letter of credit offer, a first loan offer, and a second certification verifying that the second user has issued a loan secured by the standby letter of credit, the second standby letter of credit offer being generated based on a second standby letter of credit token, the first loan offer being generated based on the first loan token; and in response to determining that the first standby letter of credit token is valid and the second certification is acceptable, recording the second standby letter of credit offer in the standby letter of credit offer pool, recording the first loan offer in a loan offer pool, and invalidating the first standby letter of credit token. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments. In the following description referring to the accompanying drawings, like reference numerals in different drawings represent the same or similar elements unless otherwise indicated.

[0009] Figure 1 is a schematic diagram of a blockchain system according to an embodiment.

[0010] Figure 2 is a schematic diagram of a computing device for implementing a node in a blockchain system according to an embodiment.

[0011] Figure 3 is a flow chart of a method for managing a standby letter of credit according to an embodiment.

[0012] Figure 4 is a flow chart of a method for managing a standby letter of credit according to an embodiment.

[0013] Figure 5 is a block diagram of an apparatus for managing a standby letter of credit according to an embodiment. DETAILED DESCRIPTION

[0014] Embodiments of this specification provide methods and apparatus for managing standby letters of credit (SBLCs). The methods and apparatus utilize a blockchain system to verify SBLCs submitted by users. Fraudulent SBLCs can be detected, and fraudulent attempts to borrow money using such SBLCs can be prevented. The methods and apparatus also implement a protocol for managing SBLCs. A borrower can be allowed to borrow up to the maximum amount allowed by the SBLC, but if it is determined that the borrower has already borrowed the maximum amount allowed, the methods and apparatus prevent additional borrowing attempts using the same SBLC. The methods and apparatus also implement a protocol for protecting privacy. In this way, the methods and apparatus can use a blockchain system to verify and record SBLCs without revealing the details of the SBLCs to the public.

[0015] Embodiments disclosed herein have one or more technical effects. In some embodiments, the method and apparatus require a user to submit proof in order to verify a user-submitted SBLC. This allows the method and apparatus to verify correctness, detect fraudulent SBLCs, and prevent fraudulent attempts to borrow money using fraudulent SBLCs. In some embodiments, the method and apparatus support the use of a blockchain system to verify the SBLC. This allows the method and apparatus to store the SBLC in a data structure that is resistant to tampering and manipulation by malicious parties. In some embodiments, the method and apparatus further support protocols for managing SBLCs using two types of commitments (e.g., SBLC commitments and loan commitments). This allows a borrower to borrow up to the maximum amount allowed by the SBLC, but if it is determined that the borrower has already borrowed the maximum amount allowed, the method and apparatus can prevent additional borrowing attempts using the same SBLC. In some embodiments, the method and apparatus further support protocols for recording only SBLC commitments and loan commitments on the blockchain system. This allows the method and apparatus to utilize the blockchain system to verify and record the SBLC without disclosing any private information to the public, thereby protecting the privacy of users who are parties to the SBLC.

[0016] Blockchain systems are implemented using peer-to-peer (P2P) networks, where nodes communicate directly with each other, e.g., without the need for a fixed central server. Each node in a P2P network can initiate communication with another node in the P2P network. Blockchain systems maintain one or more blockchains.

[0017] A blockchain is a data structure that stores data (e.g., transactions, SBLCs, etc.) in a manner that prevents malicious parties from tampering with and manipulating the data. Transactions stored in this manner can be immutable and subsequently verified. A blockchain consists of one or more blocks. Each block is linked to the immediately preceding block in the blockchain by including a cryptographic hash of the previous block. Each block may also include a timestamp, its own cryptographic hash, and one or more transactions. Transactions that have typically been verified by nodes of a blockchain system can be hashed and encoded into a data structure, such as a Merkle tree. In a Merkle tree, data at the leaf nodes of the tree are hashed, and all hashes in each branch of the tree are concatenated at the root of the branch. This process continues up the tree to the root of the entire tree, which stores hashes representing all the data in the tree. Hashes purported to be transactions stored in the tree can be quickly verified by determining whether they are consistent with the tree's structure.

[0018] A blockchain system comprises a network of computing nodes that manage, update, and maintain one or more blockchains. The network can be a public blockchain network, a private blockchain network, or a consortium blockchain network. For example, many entities (such as hundreds, thousands, or even millions of entities) can operate in a public blockchain network, with each entity operating at least one node in the public blockchain network. Thus, a public blockchain network can be considered a public network with respect to participating entities. Sometimes, a majority of entities (nodes) must sign each block for it to be valid and added to the blockchain network. Examples of public blockchain networks include specialized peer-to-peer payment networks that utilize distributed ledgers, known as blockchains.

[0019] Typically, a public blockchain network can support public transactions. Public transactions are shared by all nodes in the public blockchain network and stored in a global blockchain. The global blockchain is a blockchain that is replicated across all nodes, and all nodes reach a perfect consensus on the global blockchain. To achieve consensus (e.g., agreeing to add a block to the blockchain), a consensus protocol is implemented in the public blockchain network. Examples of consensus protocols include Proof of Work (PoW) (e.g., implemented in some cryptocurrency networks), Proof of Stake (PoS), and Proof of Authority (PoA).

[0020] Typically, a private blockchain network is provided to a specific entity, which centrally controls read and write permissions. This entity controls which nodes can participate in the blockchain network. For this reason, private blockchain networks are often referred to as permissioned networks, which impose restrictions on who is allowed to participate and their level of participation (e.g., only in certain transactions). Various types of access control mechanisms can be used (e.g., existing participants vote on the addition of new entities, and a governing body can control admission).

[0021] Typically, a consortium blockchain network can be private between participating entities. In a consortium blockchain network, the consensus process is controlled by an authorized set of nodes, one or more of which are operated by the corresponding entity (e.g., a financial institution, an insurance company). For example, a consortium of ten (10) entities (e.g., a financial institution, an insurance company) can operate a consortium blockchain network, each of which operates at least one node in the consortium blockchain network. Therefore, a consortium blockchain network can be considered a private network with respect to the participating entities. In some examples, each entity (node) must sign each block in order for the block to be valid and added to the blockchain. In some examples, at least a subset of the entities (nodes) (e.g., at least 7 entities) must sign each block in order for the block to be valid and added to the blockchain.

[0022] Figure 1 FIG2 shows a schematic diagram of a blockchain system 100 according to an embodiment. Figure 1 , the blockchain system 100 may include a plurality of nodes, such as nodes 102-110, configured to operate on a blockchain 120. The nodes 102-110 may form a network 112, such as a peer-to-peer (P2P) network. Each node 102-110 may be a computing device, such as a computer or computer system, configured to store a copy of the blockchain 120, or may be software, such as a process or application, running on a computing device. Each node 102-110 may have a unique identifier.

[0023] The blockchain 120 may include a continuously growing list of records in the form of data blocks, such as Figure 1 Each block B1-B5 may include a timestamp, a cryptographic hash of the previous block, and data of the current block, which may be a transaction such as a currency transaction. For example, Figure 1 As shown, block B5 may include a timestamp, a cryptographic hash of block B4, and transaction data for block B5. Furthermore, for example, a hash operation may be performed on a previous block to generate a cryptographic hash of the previous block. A hash operation may convert inputs of varying lengths into encrypted outputs of fixed length using a hash algorithm, such as SHA-256.

[0024] Nodes 102-110 can be configured to perform operations on blockchain 120. For example, when a node (e.g., node 102) wants to store new data on blockchain 120, the node can generate a new block to be added to blockchain 120 and broadcast the new block to other nodes (e.g., nodes 104-110) in network 112. Based on the legitimacy of the new block, for example, the validity of its signature and transactions, the other nodes can determine to accept the new block, so that node 102 and the other nodes can add the new block to their respective copies of blockchain 120. As this process repeats, more and more blocks of data can be added to blockchain 120.

[0025] Figure 2 102 ( FIG. 103 ) is a block chain system according to an embodiment of the present invention. Figure 1 )) is a schematic diagram of a computing device 200. Figure 2 , computing device 200 may include a communication interface 202 , a processor 204 , and a memory 206 .

[0026] The communication interface 202 can facilitate communication between the computing device 200 and other nodes (eg, nodes 104-110) in the implementation network. Figure 1 )) between devices. In some embodiments, the communication interface 202 is configured to support one or more communication standards, such as Internet standards or protocols, integrated services digital network (ISDN) standards, etc. In some embodiments, the communication interface 202 may include one or more of a local area network (LAN) card, a cable modem, a satellite modem, a data bus, a cable, a wireless communication channel, a radio-based communication channel, a cellular communication channel, an Internet Protocol (IP)-based communication device, or other communication devices for wired and / or wireless communication. In some embodiments, the communication interface 202 may be based on a public cloud infrastructure, a private cloud infrastructure, or a hybrid public / private cloud infrastructure.

[0027] The processor 204 may include one or more dedicated processing units, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or various other types of processors or processing units. The processor 204 is coupled to the memory 206 and is configured to execute instructions stored in the memory 206.

[0028] Memory 206 may store processor-executable instructions and data, such as a copy of blockchain 120 ( Figure 1). Memory 206 may include any type of volatile or non-volatile memory device or combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, or a magnetic or optical disk. When instructions in memory 206 are executed by processor 204, computing device 200 may perform operations on blockchain 120.

[0029] Figure 3 FIG2 is a flow chart showing a method 300 for managing a standby letter of credit (SBLC) according to an embodiment. Figure 3 , multiple users can be on a blockchain (e.g., blockchain 120 ( Figure 1 )) has an account on the blockchain. Blockchain can be implemented to support various types of users or parties, including, for example, individuals, businesses, banks, financial institutions, hospitals, and other types of companies and organizations.

[0030] For the purpose of illustration, Figure 3 Two parties are depicted in Figure 300, including an issuing bank and a beneficiary bank. A party with an account at the issuing bank may agree to act as a guarantor for a loan that a borrower wishes to take out from the beneficiary bank. In order for the beneficiary bank to accept the party as a guarantor, it may require the issuing bank to issue a SBLC. The SBLC guarantees payment from the issuing bank to the beneficiary bank if the borrower defaults on the loan. In some embodiments, if both the issuing bank and the beneficiary bank agree to record and manage the SBLC according to method 300, the beneficiary bank may be willing to accept an SBLC issued by the issuing bank.

[0031] At step 302, the issuing bank may issue an SBLC. The SBLC may be issued in various formats, including, for example, digital or paper-based formats. The SBLC may include information including, for example, the identity of the issuing bank, the beneficiary bank, the parties, the borrower, the maximum amount the borrower is allowed to borrow, the type of loan the borrower is allowed to arrange (e.g., long-term, short-term, fixed rate, or variable interest), the expiration date of the SBLC, and the like. The SBLC may also include an identifier, which may be a numeric or alphanumeric value that uniquely identifies the SBLC.

[0032] Once the SBLC is issued, at step 302, the issuing bank may generate a SBLC Commitment CM for the SBLC. SBLC In some embodiments, the issuing bank may calculate the CM by considering information about the issuing bank, the beneficiary bank, and certain information contained in the SBLC. SBLC In some embodiments, CM can be calculated based on a one-way function SBLCA person skilled in the art will understand that if a random element It is difficult to calculate And make g(y)=x, then the function It is one-way. In other words, it is difficult to calculate the value of the input variable of a one-way function from the value of its output variable, making the function practically impossible to reverse, and therefore the function is called "one-way". Hash functions, such as SHA256, are examples of one-way functions.

[0033] For example, in some embodiments, CM SBLC Can be calculated as (PK IB , PK BB , ID SBLC , V REMAIN , V SUM , D SBLC , TN SBLC , R SBLC ) of the Haab value, where PK IB and PK BB Represents the public keys of the issuing bank (IB) and the beneficiary bank (BB), and ID SBLC Indicates a logo that can be used to identify SBLC. REMAIN can represent the amount that the borrower is allowed to borrow from the beneficiary bank, and V SUM In some embodiments, V REMAIN The initial value of can be set to the maximum amount that the issuing bank is willing to guarantee, and V SUM The initial value of V can be set to 0. As will be explained below, each time the borrower borrows money from the beneficiary bank, V REMAIN can be reduced and V SUM Furthermore, as will be explained below, each time the borrower makes a repayment to the beneficiary bank, V SUM In some embodiments, when the borrower repays the beneficiary bank, V REMAIN Can remain unchanged.

[0034] To calculate CM SBLC Other variables may include D SBLC TN SBLC and R SBLC . D SBLC A hash value that can represent certain information contained in the SBLC, including, for example, the identity of the parties, the identity of the borrower, the type of loan the borrower is allowed to arrange, the expiration date of the SBLC, etc. SBLC It can be used to generate a certificate generated by the issuing bank and can be used later to make CM SBLCInvalid token number. In some embodiments, TN SBLC May include random numbers. However, it should be understood that TN SBLC It may also include alphanumeric values, and in some embodiments, TN SBLC May include a serial number. SBLC Can represent a random factor generated by the issuing bank to further protect the CM SBLC In some embodiments, R SBLC Can be a random number or a random alphanumeric value.

[0035] In some embodiments, in step 302, the issuing bank may also generate a zero-knowledge proof, represented as π SBLC Zero-knowledge proof refers to a technique that allows a prover to prove to a verifier that a statement is true without revealing any information beyond the validity of the statement itself. At step 302, the issuing bank is a prover that can prove to the blockchain or a smart contract executed on the blockchain (which serves as a verifier) that the issuing bank is the authentic issuer of the SBLC in question. The issuing bank may attempt to prove to the verifier by instructing: (1) CM SBLC well-formed, and (2) the issuing bank is indeed the issuing bank itself to prove this.

[0036] In the examples, to demonstrate that CM MSBLC Well-formed, the issuing bank can prove the promised value PK to the blockchain IB PK BB 、ID SBLC 、V REMAIN 、V SUM 、D SBLC TN SBLC and R SBLC It's CM SBLC In an embodiment, in order to prove that the issuing bank is the issuing bank itself, the issuing bank can prove to the blockchain that the issuing bank has the issuing bank's private key, or PK IB =h(SK IB ), where SK IB represents the private key known only to the issuing bank and h() is the hash function used to calculate the public key based on the private key.

[0037] In some embodiments, the issuing bank and the blockchain may agree to implement zero-knowledge proof technology, such as zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK). The issuing bank can prove to the blockchain that it knows a secret input w such that a certain relationship between public inputs x and w holds true. In some embodiments, the relationship can be defined as an arithmetic circuit. In some embodiments, the arithmetic circuit can be defined based on a polynomial equation that can be evaluated based on x and w. In some embodiments, a proving key and a verification key can be generated during a setup phase based on the arithmetic circuit and one or more security parameters established for the zero-knowledge proof. Those skilled in the art will appreciate that the setup phase can be performed by a trusted party or by multiple independent parties collaborating using multi-party computation.

[0038] In some embodiments, the issuing bank may set x to CM SBLC And set w to be based on PK IB PK BB 、ID SBLC 、V REMAIN 、D SBLC TN SBLC 、R SBLC and SK IB The generated value. For example, w can be obtained by converting PK IB PK BB 、ID SBLC 、V REMAIN 、D SBLC TN SBLC 、R SBLC and SK IB In this way, the issuing bank can use the secret and public inputs and the proving key to generate π SBLC , to prove to the blockchain that the issuing bank possesses the secret input w. In some embodiments, the blockchain may be able to verify π using the public input and the verification key generated in the setup phase SBLC In some embodiments, if the blockchain accepts the issuing bank's proof that the issuing bank possesses the secret input w, the blockchain may accept the issuing bank's statement as true.

[0039] At step 304, the issuing bank may utilize SBLC ,π SBLC} payload to submit a transaction to the blockchain. For the purpose of this description, this transaction may be referred to as an “SBLC” transaction.

[0040] At step 306, the blockchain may check πSBLC To determine whether the issuing bank possesses the secret input w. In some embodiments, the blockchain may utilize one or more smart contracts executed on the blockchain to provide this determination. A smart contract is a computer protocol implemented in the form of computer code that is incorporated into the blockchain to facilitate, verify, or enforce the negotiation or execution of a contract. For example, a user of the blockchain can program the terms of an agreement into a smart contract using a programming language such as C++, Java, Solidity, Python, etc., and when the terms are met, the smart contract can be automatically executed on the blockchain, for example, to execute a transaction. Furthermore, for example, a smart contract may include multiple subroutines or functions, each of which may be a sequence of program instructions that performs a specific task. A smart contract may be an operational code that is executed in whole or in part without human interaction.

[0041] In some embodiments, smart contracts may be incorporated into the blockchain to determine π SBLC Is it acceptable? The smart contract can use the public input and verification key to verify π SBLC If π SBLC cannot be verified, the smart contract may refuse to allow the issuing bank to proceed further. On the other hand, if π SBLC can be verified, then the smart contract can determine π SBLC is acceptable and continue to CM SBLC Recorded in the SBLC promise pool. In some embodiments, the SBLC promise pool can be constructed as a Merkle tree T SBLC and CM SBLC , and can be recorded in the Merkle tree T SBLC On the leaf node.

[0042] At step 308, the issuing bank may continue to provide the SBLC to the beneficiary bank. In some embodiments, the issuing bank may privately send the SBLC and the TN to the beneficiary bank via an off-chain communication channel. SBLC and R SBLC The issuing bank can also SBLC Alternatively or additionally, the beneficiary bank may issue a TN SBLC and R SBLC The value of CM is used to rebuild SBLC .

[0043] At step 310, the beneficiary bank may examine the SBLC to determine whether it is willing to accept the SBLC before extending the loan to the borrower. It should be understood that the beneficiary bank may consider various factors when determining whether to accept the SBLC. Such factors may include, for example, REMAIN The value of V SUMThe value of the credit score and credit history of the parties, the credit score and credit history of the borrower, the beneficiary bank’s prior transactions with the issuing bank, the parties, the borrower, etc.

[0044] If the beneficiary bank determines CM SBLC Not recorded in the SBLC commitment pool, or the recorded CM SBLC and PK IB PK BB 、ID SBLC 、V REMAIN 、V SUM 、D SBLC TN SBLC and R SBLC In this way, if the issuing bank attempts to bypass steps 304-306, or attempts to change the SBLC or TN SBLC or R SBLC If the value of , such attempts can be detected by the beneficiary bank, which can then refuse to accept the SBLC and prevent fraud.

[0045] If the beneficiary bank decides to accept the SBLC, the beneficiary bank may proceed to issue one or more loans to the borrower. If the beneficiary bank issues a loan to the borrower, the beneficiary bank may generate a loan commitment CM. SBLC The beneficiary bank can also generate a new SBLC commitment The new SBLC promises Can reflect V REMAIN Changes in the value of V (which can be reduced each time the borrower borrows from the beneficiary bank) and V SUM The Beneficiary Bank can then request the blockchain to record the new SBLC commitment. and make the previously (or recently recorded) SBLC promise CM SBLC Ineffective. In this way, Can effectively replace CM SBLC .

[0046] In some embodiments, the beneficiary bank may submit to the blockchain the SBLC Token number TN in SBLC To request blockchain invalid CM SBLC Blockchain can add TN SBLC To the used token list, indicate TN SBLC has been used or spent, which in turn may indicate to the CM SBLC No longer valid.

[0047] The beneficiary bank can generate a To generate CM SBLC For example, as mentioned above, the beneficiary bank may calculate for The hash value of PK IB PK BB 、ID SBLC and D SBLC The beneficiary bank can calculate the loan amount based on the loan amount granted to the borrower. and For example, if the loan amount is V LOAN ,but and can be calculated as and The beneficiary bank can also generate a new and In this way, the beneficiary bank can calculate a promise value that is different from the promise value calculated by the issuing bank, effectively preventing unrelated users from linking the two promise values together, which in turn prevents unrelated users from linking the issuing bank and the beneficiary bank together.

[0048] The beneficiary bank can also generate a loan commitment CM based on a one-way function LOAN In some embodiments, CM LOAN can be calculated as (PK BB , V LOAN , D LOAN , ID SBLC , TN LOAN , R LOAN ), where PK BB It can represent the public key of the beneficiary bank (BB), V LOAN can represent the outstanding amount of the loan, and D LOAN A hash value that can represent certain information contained in a loan, including, for example, the identity of the borrower, the issuance date, the maturity date, reference documents, and other terms and conditions of the loan. SBLC Can be used to identify the SBLC logo, TN LOAN It can be used to generate CM generated by the beneficiary bank. LOAN Invalid token number, R LOAN Can be generated by the beneficiary's bank for further protection of the information contained in the CM LOAN The random factor of the information in .

[0049] In step 310, the beneficiary bank can also generate a zero-knowledge proof, represented as π LOAN, proving to the blockchain that the beneficiary bank has issued a loan secured by the SBLC. In some embodiments, the beneficiary bank may generate π LOAN At this point, the beneficiary bank has already determined: (1) CM SBLC CM LOAN ,and Well-formed (i.e., correctly calculated promises), (2) CM SBLC is recorded in the SBLC commitment pool (e.g., Merkle tree T SBLC ), (3) and (4) and (5) the beneficiary bank has its private key SK BB and PK BB =h(SK BB ).

[0050] In some embodiments, the beneficiary bank and the blockchain may agree to implement the zero-knowledge proof technique described above. For example, the beneficiary bank may prove to the blockchain that the beneficiary bank knows a secret input such that for a public input x, a certain relationship between x and w holds true. In some embodiments, the beneficiary bank may set x to contain TN SBLC CM LOAN and The value of , and set w to be based on CM SBLC PK IB PK BB , ID SBLC 、D SBLC 、D LOAN 、V REMAIN 、 V SUM 、 V LOAN TN SBLC 、 TN LOAN 、R SBLC 、 R LOAN and SK BB In this way, the beneficiary bank can generate a zero-knowledge proof π LOAN To prove to the blockchain that the beneficiary bank possesses the secret input w. In some embodiments, if the blockchain accepts the beneficiary bank's proof that the beneficiary bank possesses the secret input w, the blockchain may accept the beneficiary bank's statement as true.

[0051] In step 312, the beneficiary bank may utilize For the purposes of this description, this transaction may be referred to as a "LOAN" transaction.

[0052] In step 314, the blockchain may utilize a smart contract to check the TN contained in the payload. SBLC Whether it has been used or spent. In some embodiments, the smart contract can maintain a list of used tokens on the blockchain to record the used tokens. If the TN contained in the payload SBLC is listed in the list of used tokens, the smart contract can refuse to proceed further because the beneficiary bank is trying to use a token that has already been used. On the other hand, if the TN contained in the payload SBLC is not listed in the used token list, the smart contract can continue to verify π LOAN Is it acceptable? The smart contract can use the public input and verification key to verify π LOAN .

[0053] If π LOAN Can be verified, then the smart contract can determine π LOAN is acceptable and will continue to Record in the SBLC commitment pool (as described above) and send the CM LOAN Recorded in the loan promise pool. In some embodiments, the loan promise pool can be constructed as a Merkle tree T LOAN , and CM LOAN Can be recorded in the Merkle tree T LOAN The smart contract can also add TN SBLC to the used token list to indicate TN SBLC has been used, so that TN SBLC (and therefore invalid CM SBLC ) is invalid for future use. In this way, The most recently recorded SBLC commitment that can become the SBLC and thus can be referred to as the CM in subsequent steps SBLC Furthermore, in this manner, method 300 may be used to verify and record information about an SBLC and loans issued for the SBLC on a blockchain without revealing the details of the SBLC to the public.

[0054] In some embodiments, if the beneficiary bank issues another loan to the borrower, the beneficiary bank may repeat steps 310-312, and in response, the blockchain may repeat step 314.

[0055] In some embodiments, method 300 may include additional steps defined to facilitate recording repayment information on the blockchain. For example, the beneficiary bank may utilize method 300 to record repayment information upon receipt of repayment from the borrower. Alternatively, the beneficiary bank may utilize method 300 to record repayment information according to a schedule (e.g., monthly, quarterly, or annually).

[0056] To record the repayment information, the beneficiary bank may generate a new loan commitment at step 316. To record on the blockchain and request the blockchain to invalidate the recently recorded loan commitment CM LOAN The beneficiary bank can also generate a new SBLC promise Record it on the blockchain and request the blockchain to invalidate the most recently recorded SBLC promise CM SBLC (eg, the SBLC promise previously generated at step 310 and recorded at step 314).

[0057] Beneficiary bank can be used to generate CM based on the beneficiary bank LOAN The same one-way function is used to generate As mentioned above, for example, the beneficiary bank can calculate for The hash value of PK BB 、D loan and ID SBLC The beneficiary bank can calculate the amount based on the repayments made by the borrower. In some embodiments, Value can reduce the repayment amount V REPAYMENT , making The beneficiary bank can also generate and The new value of .

[0058] The beneficiary bank can generate the As mentioned above, for example, the beneficiary bank can calculate for The hash value of PK IB PK BB 、ID SBLC The beneficiary bank can calculate the repayment based on the repayment made by the borrower. and In some embodiments, when a borrower repays an existing loan, The value can remain unchanged. On the other hand, Value can reduce the repayment amount V REPAYMENT , making The beneficiary bank can also generate and The new value of .

[0059] The beneficiary bank can submit to the blockchain the LOAN Token number TN in LOAN To request blockchain invalid CM LOANSimilarly, the beneficiary bank can submit a CM SBLC Token number TN in SBLC To request blockchain invalid CM SBLC .

[0060] In step 316, the beneficiary bank can also generate a zero-knowledge proof, represented as π REPAYMENT , to prove to the blockchain that the beneficiary bank has received the repayment of the loan secured by the SBLC. In some embodiments, the beneficiary bank may generate π REPAYMENT , at this time it has been determined that: (1) CM SBLC 、 CM LOAN and Well formed, (2)CM SBLC is recorded in the SBLC commitment pool (e.g., Merkle tree T SBLC ), (3) CM LOAN is recorded in the loan commitment pool (e.g., Merkle tree T LOAN ), (4) (5) and (6) the beneficiary bank has its private key SK BB and PK BB =h(SK BB ).

[0061] In some embodiments, the beneficiary bank and the blockchain may agree to implement the zero-knowledge proof technique described above. For example, the beneficiary bank may prove to the blockchain that the beneficiary bank knows a secret input such that for a public input x, a certain relationship between x and w holds true. In some embodiments, the beneficiary bank may set x to contain TN SBLC 、 and The value of , and set w to be based on CM SBLC CM LOAN PK IB PK BB 、ID SBLC 、D SBLC 、D LOAN 、V REMAIN 、V SUM 、 V LOAN， 、 V REPAYMENT TN SBLC 、 TN LOAN 、 R SBLC 、 RLOAN, and SKBB In this way, the beneficiary bank can generate a zero-knowledge proof π REPAYMENT To prove to the blockchain that the beneficiary bank possesses the secret input w. In some embodiments, if the blockchain accepts the beneficiary bank's proof that the beneficiary bank possesses the secret input w, the blockchain may accept the beneficiary bank's statement as true.

[0062] In step 318, the beneficiary bank may utilize For the purpose of illustration, this transaction may be referred to as a "REPAYMENT" transaction.

[0063] In step 320, the blockchain can utilize a smart contract to check the TN contained in the payload. SBLC or TN LOAN Has it been used or spent? If the payload contains TN SBLC or TN LOAN If the TN is not already used or has already been spent (e.g., listed in the used token list), the smart contract can refuse to proceed further. On the other hand, if the TN is not listed in the used token list SBLC TN is not listed either LOAN , then the smart contract can continue to verify π REPAYMENT Is it acceptable? The smart contract can use the public input and verification key to verify π REPAYMENT If π REPAYMENT can be verified, then the smart contract can determine π REPAYMENT is acceptable and will continue to Recorded in the SBLC pledge pool (as described above) and Recorded in the loan commitment pool (as described above). Smart contracts can also add TN SBLC and TN LOAN to the used token list to indicate TN SBLC and TN LOAN Already in use, thus invalidating TN SBLC and TN LOAN and for future use. In this way, and may be the most recently recorded SBLC commitment and loan commitment, which may be referred to as CM in subsequent steps, respectively. SBLC and CM LOAN Furthermore, in this manner, information regarding the SBLC and repayments made by the borrower can be verified and recorded on a blockchain using method 300 without revealing the details of the SBLC to the public.

[0064] In some embodiments, the beneficiary bank may repeat steps 316-318 to record repayment information as it receives repayments from the borrower. Alternatively, the beneficiary bank may repeat steps 316-318 to record repayment information according to a schedule (e.g., monthly, quarterly, or annually). In response, the blockchain may repeat step 320.

[0065] In some embodiments, method 300 may also support recording modifications to the SBLC. In some embodiments, only the issuing bank may have permission to modify certain information contained in the SBLC. Such information may include, for example, the maximum amount the borrower is allowed to borrow, the types of loans the borrower is allowed to arrange, and the expiration date of the SBLC.

[0066] In some embodiments, when the issuing bank modifies the SBLC, the issuing bank may use the CM generated by the issuing bank in step 302. SBLC The same one-way function generates a new SBLC promise for the modified SBLC New SBLC commitments can be generated From the reflection example D SBLC The modified value V contained in REMAIN and other values. The beneficiary bank can then request that the blockchain record the new SBLC promise And make the latest record SBLC promise CM SBLC Ineffective. In this way, Can effectively replace CM SBLC .

[0067] The issuing bank can also generate zero-knowledge proof π AMEND In some embodiments, the issuing bank may generate π AMEND At this point, the issuing bank has already determined: (1) CM SBLC and Well-formed (i.e., correctly calculated promises), (2) CM SBLC Recorded in the SBLC commitment pool (e.g., Merkle tree T SBLC ), (3) the issuing bank has its private key SK IB and PK IB =h(SK IB )(4)PK IB PK BB 、ID SBLC and V SUM In CM SBLC and Same as in.

[0068] The issuing bank can then use the The blockchain can use smart contracts to check the TN contained in the payload. SBLC Whether the TN contained in the payload (i.e., the token associated with the most recently recorded SBLC promise) has been used or spent. SBLC On the other hand, if the TN contained in the payload SBLC is not listed in the used token list, the smart contract can continue to verify π AMEND Is it acceptable?

[0069] If it can be verified, the smart contract can determine that it is acceptable and continue to record it in the SBLC promise pool (as described above). The smart contract can also add it to the list of used tokens to indicate that it has been used, thereby invalidating (and therefore invalidating) it for future use. In this way, it can become the most recently recorded SBLC promise for the modified SBLC. Moreover, in this way, method 300 can be used to verify information about the modified SBLC and record it on the blockchain without revealing the details of the modified SBLC to the public.

[0070] In some embodiments, method 300 may also support recording the cancellation of an SBLC. In some embodiments, only the issuing bank may have permission to cancel an SBLC as long as there are no outstanding loans (e.g., V SUM = 0). In some embodiments, the recording of the cancellation of the SBLC can be performed if the SBLC has a corresponding SBLC promise recorded on the blockchain. In this case, the issuing bank can simply request the blockchain to invalidate the SBLC contained in the CM SBLC However, in some embodiments, the issuing bank may still need to generate a zero-knowledge proof π CANCEL , in order to perform this cancellation process.

[0071] In some embodiments, the issuing bank may generate π CANCEL At this point, the issuing bank has already determined: (1) CM SBLC Well-formed (i.e., correctly calculated promises), (2) CM SBLC Recorded in the SBLC commitment pool (e.g., Merkle tree T SBLC ), (3) the issuing bank has its private key SK IB and PK IB =h(SK IB ), (4) included in CM SBLC The total loan amount V SUM Equal to 0.

[0072] The issuing bank can then use the SBLC ,π CANCEL} payload to submit a transaction to the blockchain. This transaction can be called a "CANCELLATION" transaction. The blockchain can use smart contracts to check the TN contained in the payload. SBLC Has it been used or spent? If TN is included in the payload SBLC On the other hand, if the TN contained in the payload SBLC is not listed in the used token list, the smart contract can continue to verify π CANCEL Is it acceptable? If π CANCEL can be verified, then the smart contract can determine π CANCEL is acceptable and continue to add TN SBLC to the used token list to indicate TN SBLC Already in use, thus invalidating TN SBLC (and therefore invalid CM SBLC ) for future use.

[0073] It should be understood that while the above example utilizes a single used token list to record all used tokens, such an implementation is provided by way of example only and is not intended to be limiting. In some embodiments, a single used token list may be utilized to record used tokens generated for SBLC commitments, while a separate used token list may be utilized to record used tokens generated for loan commitments. It should be understood that other types of data structures may also be utilized to record used tokens. Furthermore, it should be understood that the above declarations of functions, variables, and transactions are provided by way of example only and are not intended to be limiting.

[0074] Figure 4 4 is a flow chart of a method 400 for managing SBLC according to an embodiment. The method 400 may be executed by one or more nodes in a blockchain system, such as nodes 102-110 ( Figure 1 ). The nodes 102-110 in the blockchain system 100 can perform operations on the blockchain (e.g., blockchain 120 ( Figure 1 )) performs the operation. The blockchain 120 can be implemented as the blockchain in the above example.

[0075] At step 402, a node (e.g., node 102) may receive a first transaction submitted by a first user. The first user may be, for example, an issuing bank ( Figure 3 ), which is the issuer of SBLC. The first transaction may include the above-mentioned "SBLC" transaction ( Figure 3 ), which may include a first SBLC promise CM SBLCand a first certificate for proving that the first user is the issuer of the SBLC. As described above, a first SBLC promise CM may be generated based on the first SBLC token. SBLC .

[0076] At step 404, node 102 may determine a first proof π SBLC In some embodiments, the first proof π SBLC It can be a zero-knowledge proof. In some embodiments, the first user can use the first proof π SBLC To prove to node 102 that the first user possesses the secret input w. In some embodiments, if node 102 determines that the first proof is unacceptable, node 102 may report an error. On the other hand, if node 102 determines that the first proof is acceptable, node 102 may promise CM the first SBLC. SBLC Recorded in SBLC Promise Pool T SBLC middle.

[0077] At step 406, node 102 may receive a second transaction submitted by a second user. The second user may be, for example, a beneficiary bank ( Figure 3 ), which issues a loan secured by SBLC. The second transaction may include the first SBLC token TN SBLC , Second SBLC Promise First Loan Promise CM LOAN and the second proof of π LOAN As mentioned above, the Second SBLC promises Can be based on a second SBLC token Generate and first loan promise CM LOAN Can be based on the first loan token TN LOAN generate.

[0078] At step 408, node 102 may determine a first SBLC token TN SBLC Is it valid and the second proof π LOAN In some embodiments, the second proof π LOAN It can be a zero-knowledge proof. In some embodiments, the second user can use the second proof π LOAN To prove to node 102 that the second user possesses the secret input w. In some embodiments, if node 102 determines that the second proof is unacceptable, node 102 may report an error. On the other hand, if node 102 determines that the second proof is acceptable, node 102 may commit the second SBLC to Recorded in SBLC Promise Pool T LOAN The first loan will be promised to CM LOAN Recorded in the loan commitment pool T LOANand make the first SBLC token TN SBLC Ineffective. In this way, The most recently recorded SBLC commitment that can become the SBLC and thus can be referred to as the CM in subsequent steps SBLC .

[0079] At step 410, node 102 may receive a third transaction submitted by the second user. The third transaction may include the second SBLC token, the first loan token, the third SBLC promise, the second loan promise, and a third proof that the second user has received repayment for the loan secured by the SBLC. REPAYMENT In some embodiments, the third SBLC promise may be generated based on the third SBLC token, and the second loan promise may be generated based on the second loan token.

[0080] At step 412, node 102 may determine whether the second SBLC token and the first loan token are valid and the third proof π REPAYMENT In some embodiments, the third proof π REPAYMENT It can be a zero-knowledge proof. In some embodiments, the second user can use a third proof π REPAYMENT To prove to node 102 that the second user possesses the secret input w. In some embodiments, if node 102 determines that the third proof π REPAYMENT is unacceptable, node 102 may report an error. On the other hand, if node 102 determines that the third proof π REPAYMENT If the third SBLC promise is acceptable, node 102 may record the third SBLC promise in the SBLC promise pool, record the second loan promise in the loan promise pool, and invalidate the second SBLC token and the first loan token.

[0081] In some embodiments, method 400 may also support receiving the aforementioned modification and cancellation transactions. For example, at step 414, node 102 may receive a modification transaction submitted by a first user. The modification transaction may include an SBLC token associated with a recently recorded SBLC promise, a modified SBLC promise, and a modification certificate certifying that the first user is the issuer of the SBLC. Node 102 may determine whether the SBLC token associated with the recently recorded SBLC promise is valid and whether the modification certificate is acceptable. In response to determining that the SBLC token associated with the recently recorded SBLC promise is valid and the modification certificate is acceptable, node 102 may record the modified SBLC promise in the SBLC promise pool and invalidate the SBLC token associated with the recently recorded SBLC promise.

[0082] In another example, at step 416, node 102 may receive a cancellation transaction from the first user. The cancellation transaction may include an SBLC token associated with the most recently recorded SBLC offer and a cancellation certificate proving that the first user is the issuer of the SBLC. Node 102 may determine whether the SBLC token associated with the most recently recorded SBLC offer is valid and whether the cancellation certificate is acceptable. In response to determining that the SBLC token associated with the most recently recorded SBLC offer is valid and the cancellation certificate is acceptable, node 102 may invalidate the SBLC token associated with the most recently recorded SBLC offer.

[0083] Figure 5 5 is a block diagram of an SBLC management apparatus 500 according to an embodiment. The apparatus 500 may be implemented as a software process and may correspond to the method 400 ( Figure 4 ). refer to Figure 5 , the apparatus 500 may include a receiving module 502 , a determining module 504 , a recording module 506 and a reporting module 508 .

[0084] The receiving module 502 may receive the transaction submitted by the user and provide the received transaction to the determining module 504, for example, executing steps 402, 406, 410, 414, and 416 ( Figure 4 ). The determination module 504 can determine whether the token included in the transaction is still valid and whether the certificate included in the transaction is acceptable, such as performing steps 404, 408, 412, 414 and 416 ( Figure 4 If one or more tokens included in the transaction are invalid or the certificate included in the transaction is unacceptable, the determination module 504 can request the reporting module 508 to report an error; otherwise, the determination module 504 can request the recording module 506 to record the transaction and invalidate the tokens included in the transaction, as described above.

[0085] Each of the above modules can be implemented as software, or hardware, or a combination of software and hardware. For example, each of the above modules can be implemented using a processor that executes instructions stored in a memory. In addition, for example, each of the above modules can be implemented using one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors or other electronic components to perform the described method. In addition, for example, each of the above modules can be implemented by using a computer chip or entity, or by using a product with a specific function. In one embodiment, device 500 can be a computer, and the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, a game console, a tablet computer, a wearable device or any combination of these devices.

[0086] For the implementation process of the functions and effects of each module in the apparatus 500, reference may be made to the corresponding steps in the above method. For the sake of simplicity, the details are omitted here.

[0087] In some embodiments, a computer program product may include a non-transitory computer-readable storage medium having computer-readable program instructions thereon for causing a processor to execute the above-described method.

[0088] A computer-readable storage medium may be a tangible device that can store instructions used by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanical encoding device (e.g., a punch card or raised structures in grooves with instructions recorded thereon), and any suitable combination thereof.

[0089] The computer-readable program instructions for performing the above method can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data or source code or object code written in any combination of one or more programming languages (comprising object-oriented programming languages and conventional process programming languages). The computer-readable program instructions can be performed completely on a computing device as an independent software package, or partly on a first computing device and partly on a second computing device away from the first computing device. In the latter's case, the second remote computing device can be connected to the first computing device by a network of any type (comprising a local area network (LAN) or a wide area network (WAN)).

[0090] Computer-readable program instructions may be provided to a processor of a general-purpose or special-purpose computer or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the above-described methods.

[0091] The flowcharts and diagrams in the accompanying drawings illustrate the architecture, functions and operations of possible implementations of the devices, methods and computer program products according to the various embodiments of this specification. In this regard, the boxes in the flowcharts or diagrams may represent a portion of a software program, code segment or code, which includes one or more executable instructions for implementing a specific function. It should also be noted that in some alternative embodiments, the functions marked in the boxes may also occur in an order different from that marked in the figures. For example, two boxes shown in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the diagrams and / or flowcharts, and the combination of the boxes in the diagrams and flowcharts, can be implemented by a dedicated hardware-based system that performs the specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0092] It will be appreciated that certain features of this specification that, for the sake of clarity, are described in the context of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of this specification that, for the sake of brevity, are described in the context of a single embodiment may also be provided separately or in any suitable subcombination or in any other described embodiment of this specification as appropriate. Certain features described in the context of various embodiments are not essential features of those embodiments unless so indicated.

[0093] Although the present specification has been described in conjunction with specific embodiments, many alternatives, modifications and variations will be apparent to those skilled in the art. It is therefore intended that the appended claims encompass all such alternatives, modifications and variations that fall within the terms of the claims.

Claims

1. A computer-implemented method for managing a standby letter of credit (SBLC), the method comprising: receiving a first transaction from a first user, the first transaction comprising a first standby letter of credit promise and a first certification proving that the first user is an issuer of the standby letter of credit, the first standby letter of credit promise being generated based on a first standby letter of credit token; In response to determining that the first certification is acceptable, recording the first standby letter of credit commitment in a standby letter of credit commitment pool; receiving a second transaction from a second user, the second transaction comprising the first standby letter of credit token, a second standby letter of credit commitment, a first loan commitment, and a second certification certifying that the second user has issued a loan secured by the standby letter of credit, the second standby letter of credit commitment being generated based on the second standby letter of credit token, and the first loan commitment being generated based on the first loan token; as well as In response to determining that the first standby letter of credit token is valid and the second proof is acceptable, recording the second standby letter of credit promise in the standby letter of credit promise pool, recording the first loan promise in the loan promise pool, and invalidating the first standby letter of credit token.

2. The method according to claim 1, wherein The method is executed by one or more nodes in the blockchain system.

3. The method according to claim 1 or 2, further comprising one of the following: In response to determining that the first proof is unacceptable, reporting an error; or In response to determining that the first standby letter of credit token is invalid or the second proof is unacceptable, reporting an error.

4. The method according to claim 1 or 2, wherein: Each of the first standby letter of credit commitment, the second standby letter of credit commitment and the first loan commitment is generated with a random value to disassociate the first standby letter of credit commitment, the second standby letter of credit commitment and the first loan commitment.

5. The method according to claim 1 or 2, wherein: Whether the first standby letter of credit token is valid is determined based on whether the first standby letter of credit token is listed in a used token list.

6. The method according to claim 1 or 2, further comprising: receiving a third transaction from the second user, the third transaction comprising the second standby letter of credit token, the first loan token, a third standby letter of credit commitment, a second loan commitment, and a third certification certifying that the second user has received repayment of the loan secured by the standby letter of credit, the third standby letter of credit commitment being generated based on the third standby letter of credit token, and the second loan commitment being generated based on the second loan token; as well as In response to determining that the second standby letter of credit token and the first loan token are valid and the third proof is acceptable, recording the third standby letter of credit commitment in the standby letter of credit commitment pool, recording the second loan commitment in the loan commitment pool, and invalidating the second standby letter of credit token and the first loan token.

7. The method according to claim 6, further comprising: In response to determining that the second standby letter of credit token is invalid, the first loan token is invalid, or the third certification is unacceptable, an error is reported.

8. The method according to claim 1 or 2, further comprising: receiving a modification transaction from the first user, the modification transaction comprising a standby letter of credit token associated with a most recently recorded standby letter of credit commitment, a modified standby letter of credit commitment, and a modification certification certifying that the first user is the issuer of the standby letter of credit; as well as In response to determining that the standby letter of credit token associated with the most recently recorded standby letter of credit promise is valid and the modification certificate is acceptable, recording the modified standby letter of credit promise in the standby letter of credit promise pool and invalidating the standby letter of credit token associated with the most recently recorded standby letter of credit promise.

9. The method according to claim 8, further comprising: In response to determining that the standby letter of credit token associated with the most recently recorded standby letter of credit commitment is invalid or the amendment certificate is unacceptable, reporting an error.

10. The method according to claim 1 or 2, further comprising: receiving a cancellation transaction from the first user, the cancellation transaction comprising the standby letter of credit token associated with the most recently recorded standby letter of credit commitment and a cancellation certificate certifying that the first user is the issuer of the standby letter of credit; as well as In response to determining that the standby letter of credit token associated with the most recently recorded standby letter of credit promise is valid and the cancellation certificate is acceptable, invalidating the standby letter of credit token associated with the most recently recorded standby letter of credit promise.

11. The method according to claim 10, further comprising: In response to determining that the standby letter of credit token associated with the most recently recorded standby letter of credit commitment is invalid or the cancellation certificate is unacceptable, reporting an error.

12. The method according to claim 1 or 2, wherein: The proof is a zero-knowledge proof.

13. A device for managing a standby letter of credit (SBLC), comprising: one or more processors; as well as One or more computer-readable memories, coupled to the one or more processors and having instructions stored thereon, wherein the instructions are executable by the one or more processors to perform the method of any one of claims 1 to 12.

14. An apparatus for managing a standby letter of credit (SBLC), the apparatus comprising a plurality of modules for executing the method according to any one of claims 1 to 12.

15. A non-transitory computer-readable medium having stored therein instructions, which, when executed by a processor of a device, cause the device to perform the method of any one of claims 1 to 12.

Images