Methods and apparatus to facilitate split ticket financing

Abstract

This document discloses methods, apparatus, and devices for facilitating split bill financing, including computer programs stored on a computer-readable medium. One method includes: recording a public key ring comprising multiple public keys of multiple users; recording a bill token comprising an initial bill value commitment for an initial bill value; receiving a first transaction signed using the public key ring, the first transaction comprising a first loan commitment for a first loan value, a first updated bill value commitment for a first updated bill value, and a first range proof for proving that the first loan value is less than or equal to the initial bill value; and, in response to determining that the first transaction is valid, replacing the initial bill value commitment recorded for the bill token with the first updated bill value commitment.

Description

Technical Field

[0001] This specification relates generally to computer technology, and more specifically to methods and apparatus for facilitating split-note financing. Background Technology

[0002] Invoice financing is a way for businesses to borrow money using their accounts receivable (including, for example, accounts receivable from customers). Invoice financing can help businesses improve cash flow, pay employees and suppliers, and reinvest in operations and growth sooner rather than later, compared to waiting for customers to pay the full balance.

[0003] In some situations, companies may choose or may need to split their note financing. For example, if a company can only obtain note financing from a bank for a portion of the amount stated on the notes (i.e., less than the total amount), it may attempt to obtain additional note financing from one or more other banks for part or all of the remaining amount. Banks involved in these situations may want to ensure that the financing they provide is secured by the notes. However, this determination can be difficult for banks to make because they may be reluctant to share their financial information. Summary of the Invention

[0004] In one aspect, a computer-implemented method for facilitating split bill financing includes: recording a public key ring, the public key ring including multiple public keys of multiple users; recording a bill token, the bill token including an initial bill value commitment of an initial bill value; receiving a first transaction, the first transaction being signed using the public key ring, the first transaction including a first loan commitment of a first loan value, a first updated bill value commitment of a first updated bill value, and a first range proof for proving that the first loan value is less than or equal to the initial bill value; and in response to determining that the first transaction is valid based on the first loan commitment, the first updated bill value commitment, and the first range proof, replacing the initial bill value commitment recorded for the bill token with the first updated bill value commitment.

[0005] On the other hand, an apparatus for facilitating split bill financing includes: one or more processors; one or more computer-readable storage devices coupled to and storing instructions thereon that can be executed by the one or more processors to: record a public key ring including multiple public keys of multiple users; record a bill token including an initial bill value commitment for an initial bill value; receive a first transaction signed using the public key ring, the first transaction including a first loan commitment for a first loan value, a first updated bill value commitment for a first updated bill value, and a first range proof for proving that the first loan value is less than or equal to the initial bill value; and in response to determining that the first transaction is valid based on the first loan commitment, the first updated bill value commitment, and the first range proof, replace the initial bill value commitment recorded for the bill token with the first updated bill value commitment.

[0006] In another aspect, a non-transitory computer-readable medium stores instructions that, when executed by a processor of a device, cause the device to perform a method for facilitating splitting bill financing. The method includes: recording a public key ring, the public key ring including multiple public keys of multiple users; recording a bill token, the bill token including an initial bill value commitment for an initial bill value; receiving a first transaction, the first transaction being signed using the public key ring, the first transaction including a first loan commitment for a first loan value, a first updated bill value commitment for a first updated bill value, and a first range proof for proving that the first loan value is less than or equal to the initial bill value; and, in response to determining that the first transaction is valid based on the first loan commitment, the first updated bill value commitment, and the first range proof, replacing the initial bill value commitment recorded for the bill token with the first updated bill value commitment. Attached Figure Description

[0007] The accompanying drawings, which are included and form part of this document, illustrate embodiments. In the following description with reference to the drawings, unless otherwise shown, the same numerals in different drawings denote the same or similar elements.

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

[0009] Figure 2 This is a schematic diagram of a computing device for implementing nodes in a blockchain system, according to an embodiment.

[0010] Figure 3 This is a flowchart of a method for facilitating split bill financing according to an embodiment.

[0011] Figure 4This is a flowchart of a method for facilitating split bill financing according to an embodiment.

[0012] Figure 5 This is a block diagram of an apparatus for facilitating split bill financing according to an embodiment. Detailed Implementation

[0013] This specification provides embodiments of methods and apparatus for facilitating the splitting of bill financing. The methods and apparatus utilize a blockchain system to record a public key ring containing the public keys of a set of funding providers, including, for example, banks and other types of financial institutions. The methods and apparatus allow users (e.g., businesses, etc.) to request bill financing from one or more funding providers. If a funding provider approves a user's bill financing request, the funding provider can use the methods and apparatus to submit a transaction to the blockchain system and record information about the still available amount of the bill financing. In some embodiments, the information about the still available amount of the bill financing can be represented by a commitment value. The methods and apparatus can also allow funding providers to sign transactions using the public key ring. In this way, the methods and apparatus can facilitate data sharing among funding providers without requiring them to share their actual financial information with each other. Facilitating this data sharing allows funding providers to prevent users from double-financing, for example, by obtaining bill financing exceeding the total amount stated on the bill.

[0014] The embodiments disclosed in this specification have one or more technical effects. In some embodiments, the method and apparatus utilize a blockchain system to record a public key ring containing the public keys of a group of funding providers. This allows the method and apparatus to provide each funding provider in the group with the ability to sign transactions using the public key ring, effectively enabling funding providers to conceal their personal identities, which in turn helps them protect their financial information. In some embodiments, the method and apparatus may also allow funding providers to record a committed value representing the still available amount of the bill financing. This provides a mechanism for funding providers to update information about the bill financing without sharing their actual financial information with each other. In some embodiments, when a funding provider approves a user's bill financing request, the funding provider may use the method and apparatus to submit a transaction to the blockchain system and record information about the still available amount of the bill financing. This allows the method and apparatus to record information and prevent double financing. In some embodiments, the method and apparatus may further perform zero-knowledge scope proofs. This allows the method and apparatus to verify that no funding provider has disbursed financing exceeding the still available amount of the bill financing, thereby further preventing double financing.

[0015] A blockchain system, also known as a distributed ledger system (DLS) or consensus system, enables participating parties to store data securely and immutably. Without referring to any specific use case, a blockchain system can include any DLS 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 provided to specific entities that centrally control read and write permissions. Consortium blockchain networks are provided to a selected group of entities that control the consensus process, and consortium blockchain networks include an access control layer.

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

[0017] A blockchain is a data structure that stores data such as transactions in a way that prevents malicious parties from tampering with and manipulating the data. Transactions stored in this way can be immutable and subsequently verified. A blockchain consists of one or more blocks. Each block is linked to the preceding block by including its own cryptographic hash. Each block may also include a timestamp, its own cryptographic hash, and one or more transactions. Transactions that have typically been verified by nodes in the blockchain system can be hashed and encoded into a data structure such as a Merkle tree. In a Merkle tree, the data at the leaf nodes is hashed, and all hashes in each branch of the tree can be linked at the root of that branch. This process continues along the tree to the root, where hashes representing all the data in the tree are stored. A claim to have a hash of a transaction stored in the tree can be quickly verified by determining whether it is consistent with the structure of the tree.

[0018] A blockchain system comprises a network of computing nodes that manage, update, and maintain one or more blockchains. This 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, can operate in a public blockchain network, and each entity operates at least one node in the public blockchain network. Therefore, a public blockchain network can be considered a public network concerning participating entities. Sometimes, a majority of entities (nodes) must sign each block for it to be valid and added to the blockchain of the blockchain network. Exemplary public blockchain networks include specific peer-to-peer payment networks that utilize a distributed ledger called a blockchain.

[0019] Typically, public blockchain networks support public transactions. Public transactions are shared by all nodes within the public blockchain network and stored in the global blockchain. The global blockchain is a blockchain replicated across all nodes, and all nodes are in a state of full consensus relative to the global blockchain. To achieve consensus (e.g., agreeing to add blocks to the blockchain), consensus protocols are implemented in public blockchain networks. 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 can be provided to a specific entity that centrally controls read and write permissions. This entity controls which nodes can participate in the blockchain network. Therefore, private blockchain networks are often referred to as permissioned networks, which restrict who is allowed to participate in the network and the extent of their participation (e.g., only in certain transactions). Various types of access control mechanisms can be used (e.g., existing participants vote on adding new entities, and regulatory bodies can control admissions).

[0021] Typically, consortium blockchain networks are private among the participating entities. In a consortium blockchain network, consensus processing is controlled by a set of authorized nodes, one or more of which are operated by the respective entities (e.g., financial institutions, insurance companies). For example, a consortium of ten (10) entities (e.g., financial institutions, insurance companies) can operate a consortium blockchain network, with each entity operating at least one node within the network. Therefore, a consortium blockchain network can be considered a private network concerning the participating entities. In some examples, each entity (node) must sign each block 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 seven entities) must sign each block for the block to be valid and added to the blockchain.

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

[0023] Blockchain 120 can include, for example, Figure 1The data in blocks B1-B5 is a growing list of records in the form of blocks. Each of blocks B1-B5 may include a timestamp, the cryptographic hash of the previous block, and the data of the current block, which may be transactions such as currency transactions. For example, ... Figure 1 As shown, block B5 may include a timestamp, the cryptographic hash of block B4, and the transaction data of block B5. Furthermore, for example, a hash operation can be performed on the previous block to generate the cryptographic hash of the previous block. Hash operations can use hash algorithms such as SHA-256 to convert inputs of various lengths into fixed-length cryptographic outputs.

[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, it can generate a new block to be added to blockchain 120 and broadcast this new block to other nodes in network 112, such as nodes 104-110. Based on the validity of the new block, such as the validity of its signature and transactions, other nodes can determine to accept the new block, allowing node 102 and other nodes to add the new block to their respective copies of blockchain 120. By repeating this process, more and more data blocks can be added to blockchain 120.

[0025] Figure 2 The illustration shows a node (e.g., node 102) for implementation in a blockchain system according to an embodiment. Figure 1 A schematic diagram of the computing device 200. (See reference) Figure 2 The computing device 200 may include a communication interface 202, a processor 204, and a memory 206.

[0026] Communication interface 202 facilitates communication between computing device 200 and other nodes in the network (e.g., nodes 104-110). Figure 1 Communication between devices. In some embodiments, 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, communication interface 202 may include one or more of the following: local area network (LAN) card, cable modem, satellite modem, data bus, cable, wireless communication channel, radio-based communication channel, cellular communication channel, Internet Protocol (IP) based communication device, or other communication device for wired and / or wireless communication. In some embodiments, communication interface 202 may be based on public cloud infrastructure, private cloud infrastructure, or hybrid public / private cloud infrastructure.

[0027] 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. Processor 204 is coupled to memory 206 and configured to execute instructions stored in memory 206.

[0028] Memory 206 can store processor-executable instructions and data, such as blockchain 120 ( Figure 1 A copy of ), memory 206 may include any type of volatile or non-volatile memory device or a 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 storage, flash memory, or magnetic disk or optical disk. When instructions in memory 206 are executed by processor 204, computing device 200 can perform operations on blockchain 120.

[0029] Figure 3 A flowchart illustrating a method 300 for facilitating split-note financing according to an embodiment is shown. (Reference) Figure 3 Multiple users can be on the blockchain, such as Blockchain120 ( Figure 1 This allows users to have accounts. Blockchain can be implemented to support various types of users or parties, including individuals, businesses, banks, fund providers, financial institutions, hospitals, and other types of companies and organizations.

[0030] To illustrate, Figure 3 The document describes multiple users, including borrowers, managers, and a group of banks, such as bank 1 to N. In some embodiments, each bank i in the group may have a public-private key pair (Pk). i Sk i In step 302, each bank i can provide its public key Pk to sign transactions submitted to the blockchain. i The administrator can generate a public key ring R in step 304 and submit the public key ring R in step 306 for recording on the blockchain. In some embodiments, each bank i can provide its public key Pk. i Go directly to the blockchain, which can generate and record public key rings R.

[0031] In some embodiments, the public key ring R may include a list of public keys, such as {Pk1, Pk2, ..., Pk} received from the bank group. NIn some embodiments, a blockchain can utilize one or more smart contracts executed on the blockchain to verify the validity of a public key contained in a public key ring R. 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 performance of a contract. For example, blockchain users can program agreed-upon terms into a smart contract using programming languages ​​such as C++, Java, Solidity, and Python, and the smart contract can be automatically executed on the blockchain when the terms are met, such as executing a transaction. As another example, a smart contract can include multiple subroutines or functions, each of which can be a series of program instructions that perform a specific task. A smart contract can be operational code that executes without any human interaction, either fully or partially.

[0032] In some embodiments, banks 1 to N can record their public keys Pk1, Pk2, ..., Pk on the blockchain respectively. N In such an embodiment, the blockchain can utilize one or more smart contracts to verify that each public key contained in the public key ring R is recorded on the blockchain.

[0033] After the public key ring R is recorded on the blockchain, any member of the group, such as bank i∈1…N, can use the public key ring R along with its private key Sk. i Signing a transaction. For example, bank i can call the Sign() method, which signs the transaction and its private key Sk. i The public-key ring R is taken as input, and a ring signature σ is generated as output. If the signer (e.g., bank i) possesses the private key (e.g., private key Sk), then... i The private key corresponds to a public key in the public key ring R, and the signing method Sign() can generate a valid ring signature σ. Then, the signing method Sign() can be used to allow the use of the public key ring R (instead of using the public key Pk of bank i). i The ring signature σ is generated in a way that verifies its validity. In this way, bank i can conceal its identity by signing transactions using the ring signature σ. In other words, the transaction appears to other users (including other banks in the group) as if it had been signed by a member of that group. However, other users may not be able to determine which member of the group signed the transaction.

[0034] In step 308, borrowers interested in obtaining bill financing can generate a bill token T to be recorded on the blockchain. The bill token T can be generated based on the bill information issued by the borrower. Such information may include, for example, the borrower's identity or identifier, a description of the product or service provided by the borrower to the purchaser, the identity or identifier of the purchaser of the provided product or service, the outstanding balance, payment terms, etc.

[0035] In some embodiments, the bill token T may include a token identifier ID and a commitment value comm(v). The token identifier ID may represent an identifier that can be used to identify the bill token T. The commitment value comm(v) may represent the committed value of the total remaining value v of the bill. In some embodiments, the total remaining value v may represent the remaining outstanding balance in the bill that can still be used to obtain bill financing. In some embodiments, the initial value of v may be set to the outstanding balance stated in the bill, which may serve as the maximum amount that the borrower can use to obtain bill financing. For ease of illustration, the maximum amount that the borrower can use to obtain bill financing may be denoted as max.

[0036] After determining the initial value of v, its commitment value comm(v) can be calculated based on a commitment scheme. The commitment scheme can include a cryptographic primitive that allows the borrower to commit to a value of v while hiding that value from others. In this way, the borrower can simply submit the commitment value comm(v) as part of the bill token T to the blockchain, thereby using this commitment value to prevent double financing. As described below, the blockchain can allow the borrower to borrow from a set of banks, including bank 1 to bank N, up to the initial value of v. However, if the blockchain determines that the borrower has already borrowed up to the initial value of v, it can reject other borrowing attempts by the borrower using the same bill.

[0037] In some embodiments, the commitment scheme used to calculate the commitment value comm(v) may be additively homomorphic, meaning that for a given value x and a given value y, the commitment scheme specifies that It equals comm(x+y), where This represents an algebraic operation (e.g., addition or multiplication) that can be performed on comm(x) and comm(y). In some embodiments, the commitment scheme used may be a Pedersen commitment scheme, for example, as disclosed by Torben Pryds Pedersen in “Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing,” Advances in Cryptology—CRYPTO 91 Procs., Lecture Notes in Computer Science, vol. 576, pp. 129-140, 1991, which is incorporated herein by reference in its entirety. The Pedersen commitment value of value v can be represented as Where PC() represents the Pedersen commitment value, v represents the value used to calculate the Pedersen commitment value, and r v`x` is a random number used to generate the Pedersen commitment value for the value `v`, and `g` and `h` are generator values. The Pedersen commitment scheme is additively homomorphic, meaning that `PC(x, r)`... x PC(y, r) y ) = PC(x+y, r x +r y ).

[0038] It should be understood that the Pedersen commitment described above is merely an example and is not intended to be limiting. It is anticipated that other commitment schemes can be used to replace or supplement the Pedersen commitment. It should also be understood that the Pedersen commitment value of v, in the example above, is denoted as PC(v, r). v The commitment value of v is just one example, comm(v). Therefore, for illustrative purposes, the following description may refer more generally to the commitment value of v as comm(v).

[0039] In some embodiments, the borrower may generate a note token T to include an optional data field d, which may include other information contained in the note. Data field d may include information relating to, for example, the borrower's identity or identifier, a description of the product or service provided by the borrower to the purchaser, the purchaser's identity or identifier, payment terms, etc. In some embodiments, data field d may be encrypted, and in some implementations, data field d may be included to meet regulatory audit requirements. In such embodiments, data field d may be encrypted using the regulatory agency's public key.

[0040] In some embodiments, the borrower may sign the bill token T using their private key. In some embodiments, the borrower may also request the bill recipient (e.g., the purchaser of the product or service offered) and / or a trusted entity (e.g., a government agency) to sign the bill token T using their respective private keys to further verify the authenticity of the bill. The borrower may submit the bill token T to the blockchain.

[0041] In step 310, the blockchain may record the bill token T submitted by the borrower. In some embodiments, the blockchain may require the borrower to provide a range proof π to demonstrate that the commitment value comm(v) contained in the bill token T is calculated based on v, where v is greater than 0 and less than or equal to the maximum amount the borrower is allowed to borrow (i.e., 0 < v ≤ max). In some embodiments, if the borrower fails to provide a satisfactory range proof π, the blockchain may refuse to record the bill token T submitted by the borrower. In some embodiments, the blockchain may accept a range proof π as a zero-knowledge range proof, for example, as disclosed by J. Camenisch et al. in “Efficient Protocols for Set Membership and Range Proofs,” ASIACRYPT 2008, LNCS, vol. 5350, pp. 234-252, or by B. Bunz et al. in “Bulletproofs: Short Proofs for Confidential Transactions and More,” IEEE Symposium on Security and Privacy, IEEE 2018, both of which are incorporated herein by reference in their entirety. Understandably, accepting zero-knowledge range proofs allows borrowers to prove 0 < v ≤ max to the blockchain without disclosing the actual value of v. It's also important to understand that zero-knowledge range proofs π can be generated using various schemes, including but not limited to Bulletproof, Borromean Ring signature, and Boneh-Boyen signature schemes. In this way, borrowers only need to disclose the commitment value comm(v) to the blockchain, which allows them to keep the potential value of v private.

[0042] In step 312, the borrower may request bill financing from a bank, such as Bank 1. In some embodiments, the borrower may privately send information about the bill and the bill token T to Bank 1 via an off-chain communication channel. Such information may include, for example, the token identifier ID of the bill token T, the value of v, and the commitment scheme used by the borrower to calculate comm(v). If the borrower uses a Pedersen commitment to calculate comm(v), i.e., comm(v) = PC(v, r v Then the borrower can provide bank 1 with r v The value of the data field. Borrowers may also voluntarily or at the request of Bank 1 send additional information to Bank 1. Such additional information may include, for example, a description of the product or service offered, the identity or identifier of the purchaser, payment terms, etc. In some embodiments, the additional information may include the information contained in the aforementioned data field d.

[0043] In step 314, Bank 1 may decide whether to provide bill financing to the borrower. In some embodiments, Bank 1 may attempt to retrieve a bill token T from the blockchain using a token identifier ID provided by the borrower. If the bill token T cannot be retrieved, Bank 1 may refuse to process the borrower's bill financing request. If the bill token T can be retrieved, Bank 1 may calculate comm(v) based on the value of v received in step 312 and compare the calculated comm(v) with the comm(v) recorded in the bill token T. If the calculated comm(v) does not match the comm(v) recorded in the bill token T, Bank 1 may refuse to proceed further because the borrower may have changed the value. v Similarly, if Bank 1 has received additional information from the borrower, including information contained in data field d, Bank 1 can encrypt the additional information received in step 312 and compare the encryption result with the encrypted data field d recorded in the bill token T. If the encryption result calculated by Bank 1 does not match the encrypted data field d recorded in the bill token T, Bank 1 can refuse to proceed further because the borrower may have altered the information contained in data field d.

[0044] Bank 1 may also consider various other factors when determining whether to provide note financing to a borrower. These factors may include, for example, the value of v, the amount of financing sought by the borrower, the borrower's credit score and credit history, and previous transactions between Bank 1 and the borrower. Other factors may include, for example, the buyer's credit score and previous transactions between Bank 1 and the buyer.

[0045] If Bank 1 decides to reject a borrower's bill financing request, Bank 1 can privately communicate this decision to the borrower through off-chain communication channels. In this case, the borrower can choose to repeat step 312 and request bill financing from another bank. On the other hand, if Bank 1 decides to provide the borrower with bill financing for a specific loan amount, for example, a1, Bank 1 can communicate this decision to the borrower and generate a transaction to update the bill token T recorded on the blockchain.

[0046] In some embodiments, a transaction generated by bank 1 may include the token identifier ID of the bill token T, the commitment value comm(a1) of the loan amount a1, and the total remaining value v of the updated bill. updated The commitment value comm(v) updated In some embodiments, bank 1 can calculate v by subtracting the loan amount a1 from the total residual value v before disbursing the loan. updated That is, v updated =v-a1.

[0047] In some embodiments, the transaction generated by bank 1 may also include a range proof π, which proves that the loan amount a1 is greater than 0 and less than or equal to v (i.e., 0 < a1 ≤ v). In some embodiments, bank 1 may generate a range proof π as a zero-knowledge range proof, thereby allowing bank 1 to prove 0 < a1 ≤ v to the blockchain without disclosing the actual value of a1 to the blockchain.

[0048] In step 316, Bank 1 can submit the transaction to the blockchain for recording. For illustrative purposes, this transaction may be referred to as an UPDATE transaction. In some embodiments, Bank 1 can sign the UPDATE transaction using a ring signature σ generated based on Bank 1's private key and public key ring R as described above. It is important to note that using the ring signature σ to sign the UPDATE transaction allows Bank 1 to conceal its identity. In other words, Bank 1 can simply identify itself as a member of a group that includes Banks 1 through N. However, other users (including other banks in the same group) may not be able to determine which member of the group signed this UPDATE transaction.

[0049] In step 318, the blockchain can utilize a smart contract to verify the validity of the UPDATE transaction. In some embodiments, the smart contract can be based on the ring signature σ, the range proof π contained in the UPDATED transaction, and the commitment values ​​comm(a1) and comm(v). updated This is used to verify the validity of the UPDATE transaction.

[0050] For example, in some embodiments, the smart contract can verify the validity of the ring signature σ used to sign the UPDATE transaction. In some embodiments, the smart contract can use a public key ring R to verify the validity of the ring signature σ. If the ring signature σ cannot be verified using the public key ring R, the smart contract can conclude that Bank 1 does not know the private key corresponding to a public key in the public key ring R. Therefore, the smart contract can conclude that Bank 1 is not a member of the group including Banks 1 through N. The smart contract can therefore consider the UPDATE transaction invalid and refuse to proceed further.

[0051] Similarly, in some embodiments, the smart contract can determine whether the range proof π contained in the UPDATE transaction is acceptable. If the smart contract determines that the range proof π contained in the UPDATE transaction is unacceptable—for example, the range proof π cannot prove 0 < a1 ≤ v—the smart contract can consider the UPDATE transaction invalid and refuse to proceed further.

[0052] Smart contracts can also determine the commitment values ​​comm(a1) and comm(v) included in the UPDATE transaction. updatedIs it acceptable? For example, a smart contract can retrieve a ticket token T from the blockchain using the token identifier ID included in the UPDATE transaction. The smart contract can then retrieve the latest value of comm(v) for the record of ticket token T and subtract ccomm(a1) from comm(v) to calculate the value of comm(v) - comm(a1) (or comm(v) / comm(a1), depending on the homomorphic properties of the commitment scheme used). If the calculated value of comm(v) - comm(a1) (or comm(v) / comm(a1)) is consistent with the value of comm(v) included in the UPDATE transaction... updated If the value of comm(v) - comm(a1) (or comm(v) / comm(a1)) does not match the value of comm(v) in the UPDATE transaction, the smart contract can consider the UPDATE transaction invalid and refuse to proceed further. Otherwise, if the calculated value of comm(v) - comm(a1) (or comm(v) / comm(a1)) does not match the value of comm(v) in the UPDATE transaction, the smart contract can consider the UPDATE transaction invalid and refuse to proceed further. updated If the value of ) matches, the smart contract can update the ticket token T and use the received comm(v) to... updated The value of ) replaces the latest value of comm(v). In this way, comm(v) updated This can become the latest value of comm(v) in subsequent steps. Furthermore, in this way, information about the total remaining value of the bill can be verified and recorded on the blockchain without disclosing the actual total remaining value of the bill to the public.

[0053] In step 320, the borrower may proceed to request bill financing from another bank, such as Bank 2. In some embodiments, the borrower may privately send information about the bill and the bill token T to Bank 2 via off-chain communication channels. Such information may include, for example, the token identifier ID of the bill token T, the latest value of v, and the commitment scheme used by the borrower. Notably, the latest value of v should now reflect the total remaining value of the bill after the update. In other words, the loan amount a1 should now be subtracted from v, as it has already been used to obtain the loan from Bank 1. The borrower may also voluntarily or at Bank 2's request send additional information to Bank 2. Such additional information may include, for example, a description of the product or service provided by the borrower to the purchaser, the purchaser's identity or identifier, payment terms, etc.

[0054] In step 322, Bank 2 may decide whether to provide bill financing to the borrower. In some embodiments, Bank 2 may attempt to retrieve a bill token T from the blockchain using a token identifier ID provided by the borrower. If the bill token T cannot be retrieved, Bank 2 may refuse to process the borrower's bill financing request. If the bill token T can be retrieved, Bank 2 may calculate comm(v) based on the value of v received in step 320 and compare the calculated comm(v) with the comm(v) recorded in the bill token T. If the calculated comm(v) does not match the comm(v) recorded in the bill token T, Bank 2 may refuse to proceed further because the borrower may have changed the value of v. Similarly, if Bank 2 has received additional information from the borrower, including information contained in data field d, Bank 2 may encrypt the additional information received in step 320 and compare the encryption result with the encrypted data field d recorded in the bill token T. If the encryption result calculated by Bank 2 does not match the encrypted data field d recorded in the bill token T, Bank 2 may refuse to proceed further because the borrower may have changed the information contained in data field d.

[0055] Bank 2 may also consider various other factors when determining whether to provide note financing to a borrower. These factors may include, for example, the value of v, the amount of financing sought by the borrower, the borrower's credit score and credit history, and previous transactions between Bank 2 and the borrower. Other factors may include, for example, the purchaser's credit score and previous transactions between Bank 2 and the purchaser. In some embodiments, if the value of v is already set to zero, Bank 2 may reject the borrower's note financing request, thereby effectively preventing the borrower from double-financing.

[0056] If Bank 2 decides to reject a borrower's bill financing request, Bank 2 can privately communicate this decision to the borrower through off-chain communication channels. In this case, the borrower can choose to repeat step 320 and request bill financing from another bank. On the other hand, if Bank 2 decides to provide the borrower with bill financing for a specific loan amount, for example, a2, Bank 2 can communicate this decision to the borrower and generate another UPDATE transaction to update the bill token T recorded on the blockchain.

[0057] In some embodiments, the UPDATE transaction generated by bank 2 may include the token identifier ID of the bill token T, the commitment value comm(a2) of the loan amount a2, and the total remaining value v of the updated bill. updated The commitment value comm(v) updated In some embodiments, bank 2 can calculate v by subtracting the loan amount a2 from the total residual value v before disbursing the loan. updated That is, v updated=v-a2.

[0058] In some embodiments, the transaction generated by bank 2 may also include a range proof π, which proves that the loan amount a2 is greater than 0 and less than or equal to v (i.e., 0 < a2 ≤ v). In some embodiments, bank 2 may generate a range proof π as a zero-knowledge range proof, thereby allowing bank 2 to prove 0 < a2 ≤ v to the blockchain without disclosing the actual value of a2 to the blockchain.

[0059] In step 324, Bank 2 can submit the UPDATE transaction to the blockchain for recording. In some embodiments, as described above, Bank 2 can sign the UPDATE transaction using a ring signature σ generated based on Bank 2's private key and public key ring R. It is important to note that using the ring signature σ to sign the UPDATE transaction allows Bank 2 to conceal its identity. In other words, Bank 2 can simply identify itself as a member of a group that includes Banks 1 through N. However, other users (including other banks in the same group) may not be able to determine which member of the group signed the UPDATE transaction.

[0060] In step 326, the blockchain can utilize a smart contract to verify the validity of the UPDATE transaction. In some embodiments, the smart contract can be based on the ring signature σ, the range proof π contained in the UPDATED transaction, and the commitment values ​​comm(a2) and comm(v). updated This is used to verify the validity of the UPDATE transaction.

[0061] For example, in some embodiments, the smart contract can verify whether the ring signature σ used to sign the UPDATE transaction is valid. In some embodiments, the smart contract can use a public key ring R to verify the validity of the ring signature σ. If the ring signature σ cannot be verified using the public key ring R, the smart contract can consider the UPDATE transaction invalid and refuse to proceed further.

[0062] Similarly, in some embodiments, the smart contract can determine whether the range proof π contained in the UPDATE transaction is acceptable. If the smart contract determines that the range proof π contained in the UPDATE transaction is unacceptable—for example, the range proof π cannot prove 0 < a² ≤ v—the smart contract can consider the UPDATE transaction invalid and refuse to proceed further.

[0063] Smart contracts can also determine the commitment values ​​comm(a2) and comm(v) included in the UPDATE transaction. updatedIs it acceptable? For example, a smart contract can retrieve a ticket token T from the blockchain using the token identifier ID included in the UPDATE transaction. The smart contract can then retrieve the latest value of comm(v) from the ticket token T and subtract comm(a2) from comm(v) to calculate the value of comm(v) - comm(a2). If the calculated value of comm(v) - comm(a2) is consistent with the value of comm(v) included in the UPDATE transaction... updated If the value of comm(v) - comm(a2) does not match the value of comm(v) in the UPDATE transaction, the smart contract can consider the UPDATE transaction invalid and refuse to proceed further. Otherwise, if the calculated value of comm(v) - comm(a2) does not match the value of comm(v) in the UPDATE transaction, the smart contract can consider the UPDATE transaction invalid and refuse to proceed further. updated If the value of ) matches, the smart contract can update the ticket token T and use the received comm(v) to... updated The value of ) replaces the latest value of comm(v). In this way, comm(v) updated This can become the latest value of comm(v) in subsequent steps. Furthermore, in this way, information about the total remaining value of the bill can be verified and recorded on the blockchain without disclosing the actual total remaining value of the bill to the public.

[0064] It should be understood that steps 320 to 326 can be repeated, and each time steps 320 to 326 are repeated, a new commitment value comm(v) can be calculated for the ticket token T. updated This replaces the value already recorded in comm(v). In this way, method 300 allows the borrower to borrow the initial value v set by the borrower when the borrower initially generates the note token T, where 0 < v ≤ max. After the borrower has borrowed up to the initial value v, method 300 can reject any further attempts by the borrower to borrow using the note token T.

[0065] Figure 4 A flowchart illustrating a method 400 for facilitating split-note financing according to an embodiment is shown. Method 400 can be executed by one or more nodes in a blockchain system, for example, blockchain system 100 (…). Figure 1 Nodes 102-110 in blockchain system 100 can perform operations on the blockchain, such as blockchain 120. Figure 1 Blockchain 120 can be implemented as the blockchain in the example above.

[0066] In step 402, a node (e.g., node 102) may record a public key ring (e.g., public key ring R) on blockchain 120. The public key ring may include multiple public keys from multiple users. Users may include, for example, banks 1 to N as described above.

[0067] In step 404, node 102 can record a bill token, such as bill token T, on blockchain 120. The bill token can be issued by the borrower (e.g., Figure 3 The bill token is generated based on the bill issued by the borrower. In some embodiments, the bill token may include an initial bill value commitment comm(v) of an initial bill value v. In some embodiments, the initial bill value v may be set to the outstanding balance stated in the bill, which may serve as the maximum amount the borrower can use to obtain bill financing. In some embodiments, the bill token may also include an identifier and data fields. In some embodiments, the bill token may be signed by the borrower using the borrower's private key. In some embodiments, the borrower may also request the recipient and / or trusted entity of the bill to sign the bill token using their respective private keys to further prove the authenticity of the bill. In some embodiments, the borrower may provide a range proof to prove that the initial bill value commitment comm(v) included in the bill token is calculated based on the initial bill value v, which is greater than 0 and less than or equal to the maximum amount the borrower is allowed to borrow. In some embodiments, if the bill token is correctly signed and the range proof provided by the borrower is acceptable, node 102 may record the bill token on blockchain 120.

[0068] In step 406, node 102 can receive the first transaction, for example, an UPDATE transaction received from bank 1. Figure 3 The first transaction may include a first loan commitment comm(a1) of a first loan value a1, where the first loan value a1 may represent the amount of bill financing that Bank 1 decides to provide to the borrower. The first transaction may also include a first updated bill value v. updated The first updated ticket value promise comm(v) updated ), where the first updated ticket value v updated This can represent the updated value of v after the first loan is disbursed. The first transaction may also include a first range proof to prove that, prior to the disbursement of the first loan, the first loan value a1 is less than or equal to the initial note value v.

[0069] In step 408, node 102 can determine the validity of the first transaction, and in response to determining the validity of the first transaction, replace the initial ticket value commitment comm(v) for the ticket token record with the first updated ticket value commitment comm(v). updated ).

[0070] In some embodiments, node 102 may determine the validity of the first transaction based on whether the first transaction was signed by one of the multiple users using a public key ring. If the first transaction was not signed by one of the multiple users using a public key ring, node 102 may consider the first transaction invalid and refuse to proceed further. In some embodiments, if node 102 considers the first transaction invalid, node 102 may report an error.

[0071] In some embodiments, node 102 may also determine the validity of the first transaction based on whether the proof contained in the first transaction is acceptable. If the first range proof contained in the first transaction is unacceptable, for example, if the first range proof fails to prove that the first loan value a1 is less than or equal to the initial bill value v before the loan is disbursed, then node 102 may consider the first transaction invalid and refuse to proceed further.

[0072] In some embodiments, node 102 may also be based on an initial bill value commitment comm(v), a first loan commitment comm(a1), and a first updated bill value commitment comm(v). updated The validity of the first transaction is determined by whether a predetermined algebraic relationship holds between the commitments. In some embodiments, the commitment can be calculated based on an additive homomorphic commitment scheme. In such an embodiment, the predetermined algebraic relationship may mean that the initial bill value commitment comm(v) minus or divided by the first loan commitment comm(a1) should equal the first updated bill value commitment comm(v). updated In this way, if node 102 determines that the predetermined algebraic relationship between the initial bill value commitment, the first loan commitment, and the first updated bill value commitment does not hold, node 102 can consider the first transaction invalid and refuse to proceed further. Otherwise, if the predetermined algebraic relationship holds, node 102 can update the bill token and use the first updated bill value commitment comm(v) updated Replace the initial ticket value commitment comm(v) for the ticket token record. In this way, comm(v) updated This can become the latest value of comm(v) in subsequent steps.

[0073] In step 410, node 102 can receive a second transaction, for example, an UPDATE transaction received from bank 2. Figure 3The second transaction may include a second loan commitment comm(a2) of a second loan value a2, wherein the second loan value a2 may represent the amount of bill financing that Bank 2 decides to provide to the borrower. The second transaction may also include a second updated bill value commitment of a second updated bill value, wherein the second updated bill value may represent the updated value of v after the second loan is disbursed. The second transaction may also include a second scope proof for proving that the second loan value a2 is less than or equal to the first updated bill value before the second loan is disbursed.

[0074] In step 412, node 102 can determine the validity of the second transaction and, in response to determining the validity of the second transaction, replace the first updated bill value commitment (i.e., the latest value of comm(v)) for the bill token record with the second updated bill value commitment. Node 102 can determine the validity of the second transaction based on whether the second transaction was signed by one of multiple users using the public key ring, whether the range proof contained in the second transaction is acceptable, or whether a predetermined algebraic relationship holds between the first updated bill value commitment (which is now the latest value of comm(v), the second loan commitment comm(a2), and the second updated bill value commitment. If the predetermined algebraic relationship holds, node 102 can update the bill token and replace the value of comm(v) for the bill token record with the second updated bill value commitment. In this way, the second updated bill value commitment can become the latest value of comm(v), and steps 410 and 412 can be repeated for another transaction, such as another UPDATE transaction received from another bank.

[0075] Figure 5 This is a block diagram of an apparatus 500 for facilitating split-note financing according to an embodiment. Apparatus 500 may be an implementation of software processing and may correspond to method 400 (…). Figure 4 ). refer to Figure 5 The device 500 may include a receiving module 502, a determining module 504, a recording module 506, and a reporting module 508.

[0076] The receiving module 502 can receive public key rings submitted by one or more users, such as the administrator or bank 1 to N mentioned above. Figure 3 The public key ring can include multiple public keys from multiple users. Users can include, for example, banks 1 to N. The receiving module 502 can provide the received public key ring to the recording module 506, which can record the received public key ring. The receiving module 502 can also receive the borrower's (e.g., a note issued by the borrower) public key ring based on the note issued by the borrower. Figure 3The receiving module 502 can provide the received bill token to the recording module 506, which can record the received bill token. The receiving module 502 can also receive bill tokens from one or more users, including, for example, banks 1 to N. Figure 3 The received transaction is then submitted. The receiving module 502 can provide the received transaction to the determining module 504.

[0077] The determining module 504 can determine whether a transaction is valid. In some embodiments, the determining module 504 can determine whether a transaction is valid based on whether it was signed by one of a group of users using a public key ring. In some embodiments, the determining module 504 can determine whether a transaction is valid based on whether the range proof included in such a transaction is acceptable. In some embodiments, the determining module 504 can determine whether a transaction is valid based on whether a predetermined algebraic relationship holds between certain commitment values ​​included in the transaction. In response to determining that a transaction is invalid, the determining module 504 can request the reporting module 508 to report an error. Otherwise, as described above, the determining module 504 can provide the transaction to the recording module 506, which can record the transaction and update the recorded ticket token based on the transaction.

[0078] Each of the above modules can be implemented as software, hardware, or a combination of both. For example, each of the above modules can be implemented using a processor, and memory executes instructions stored in memory. Furthermore, 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 methods. Further, for example, each of the above modules can be implemented using a computer chip or entity, or by using a product with specific functionality. In an embodiment, device 500 can be a computer, and the computer can be a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of these devices.

[0079] For the implementation process of the function and role of each module in device 500, please refer to the corresponding steps in the above method. For the sake of simplicity, details are omitted here.

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

[0081] Computer-readable storage media can be tangible devices that store instructions for use by an instruction execution device. Such computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital versatile optical disc (DVD), memory sticks, floppy disks, mechanical encoding devices (e.g., punched cards or raised structures in recesses on which instructions are recorded), and any suitable combination thereof.

[0082] The computer-readable program instructions used to perform the above methods can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​and traditional procedural programming languages. The computer-readable program instructions can be executed entirely as a standalone software package on the computing device, or partially on the first computing device and partially on a second computing device located remotely from the first computing device. In the latter case, the second remote computing device can be connected to the first computing device via any type of network, including a local area network (LAN) or a wide area network (WAN).

[0083] 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 are executed via the processor of the computer or other programmable data processing apparatus to create a mechanism for carrying out the methods described above.

[0084] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this document. In this regard, the boxes in the flowcharts or block diagrams may represent segments or portions of software programs or code, which include one or more executable instructions for implementing a particular function. It should also be noted that in some alternative embodiments, the functions mentioned in the boxes may not occur in the order shown in the figures. For example, two boxes shown consecutively may actually be executed substantially simultaneously, or these boxes may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each box in the figures and / or flowcharts, as well as combinations of boxes in the figures and flowcharts, may be implemented by a hardware-based system for a special purpose performing a specified function or action, or by a combination of special-purpose hardware and computer instructions.

[0085] It should be understood that, for clarity, certain features of this disclosure described in the context of different embodiments may also be provided in combination in a single embodiment. Conversely, for brevity, various features of this disclosure described in the context of a single embodiment may also be provided individually or in any suitable sub-combination, or suitably provided in any other described embodiment of this disclosure. Unless otherwise stated, certain features described in the context of various embodiments are not essential features of those embodiments.

[0086] Although this disclosure has been described in conjunction with specific embodiments, many substitutions, modifications, and variations will be apparent to those skilled in the art. Therefore, the following claims encompass all such substitutions, modifications, and variations that fall within the scope of the claims.

Claims

1. A computer-implemented method for facilitating split-note financing, the method comprising: Record a public key ring, wherein the public key ring includes multiple public keys from multiple funding providers; Record a ticket token, the ticket token including an initial ticket value commitment of the initial ticket value; Receive a first transaction, the first transaction being a ring signature obtained by a first fund provider among the plurality of fund providers based on its private key and the public key ring signing, the first transaction including a first loan commitment for a first loan value, a first updated bill value commitment for a first updated bill value, and a first range proof for proving that the first loan value is less than or equal to the initial bill value; as well as The ring signature is verified using the public key ring. After successful verification, in response to determining that the first transaction is valid based on the first loan commitment, the first updated bill value commitment, the initial bill value commitment, and the first range proof, the initial bill value commitment for the bill token record is replaced with the first updated bill value commitment.

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, further comprising: The first transaction is determined to be valid if the following conditions are met: The first transaction is signed by one of the plurality of users using the public key ring, the first scope proof is acceptable, and The predetermined algebraic relationship between the initial bill value commitment, the first loan commitment, and the first updated bill value commitment holds.

4. The method according to claim 3, further comprising one of the following: In response to determining that the first transaction was not signed by one of the plurality of users using the public key ring, an error is reported; In response to the determination that the first range proves the first loan value is less than or equal to the initial bill value, an error is reported; or An error is reported in response to the determination that the predetermined algebraic relationship between the initial bill value commitment, the first loan commitment, and the first updated bill value commitment does not hold.

5. The method according to any one of claims 3-4, wherein, The predetermined algebraic relation indicates that the initial bill value commitment minus the first loan commitment equals the first updated bill value commitment.

6. The method according to any one of claims 3-4, wherein, The predetermined algebraic relation indicates that the initial bill value commitment divided by the first loan commitment equals the first updated bill value commitment.

7. The method according to claim 1, wherein, The first range proof is a zero-knowledge range proof, used to prove that the first loan value is less than or equal to the initial bill value without disclosing the first loan value.

8. The method of claim 1, wherein the commitment is a Pedersen commitment.

9. The method according to claim 1, further comprising: Receive a second transaction, the second transaction being signed using the public key ring, the second transaction including a second loan commitment for a second loan value, a second updated bill value commitment for a second updated bill value, and a second range proof for proving that the second loan value is less than or equal to the first updated bill value; as well as In response to determining the validity of the second transaction based on the second loan commitment, the second updated bill value commitment, and the second scope proof, the first updated bill value commitment for the bill token record is replaced with the second updated bill value commitment.

10. The method of claim 9, further comprising: The second transaction is deemed valid if the following conditions are met: The second transaction is signed by one of the plurality of users using the public key ring, and the second scope proof is acceptable. The predetermined algebraic relationship between the first updated note value commitment, the second loan commitment, and the second updated note value commitment holds.

11. The method according to any one of claims 9-10, wherein, The second range proof is a zero-knowledge range proof used to prove that the second loan value is less than or equal to the first updated note value without disclosing the second loan value.

12. The method according to claim 1, wherein, The multiple users include multiple bill financing providers.

13. A computer-implemented apparatus for facilitating splitting of bill financing, comprising: One or more processors; as well as One or more computer-readable storage devices are coupled to the one or more processors and have instructions stored thereon that can be executed by the one or more processors to perform the method of any one of claims 1 to 12.

14. An apparatus for facilitating split bill financing, the apparatus comprising a plurality of modules for performing the method of any one of claims 1 to 12.

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

Images