CN114930372A

CN114930372A - Method and apparatus for facilitating split-note financing

Info

Publication number: CN114930372A
Application number: CN202080092357.0A
Authority: CN
Inventors: 曹圣皎; 袁园; 方晖; 杨伟涛
Original assignee: Alipay Labs Singapore Pte Ltd
Current assignee: Alipay Labs Singapore Pte Ltd
Priority date: 2020-01-09
Filing date: 2020-12-26
Publication date: 2022-08-19
Also published as: SG10202000214WA; WO2021139545A1

Abstract

Methods, apparatus, and devices, including computer programs stored on computer-readable media, for facilitating split-ticket financing are disclosed herein. One of the methods comprises: recording a public key ring including a plurality of public keys of a plurality of users; recording a ticket token for an initial ticket value commitment including an initial ticket value; receiving a first transaction signed using a public key ring, the first transaction comprising a first loan commitment to a first loan value, a first update instrument value commitment to a first update instrument value, and a first range attestation to attest that the first loan value is less than or equal to the initial instrument value; and, in response to determining that the first transaction is valid, replacing the initial ticket value commitment to the ticket token record with a first updated ticket value commitment.

Description

Method and apparatus for facilitating split-note financing

Technical Field

This specification relates generally to computer technology and, more particularly, to methods and apparatus for facilitating split instrument financing.

Background

Bill financing (invoicing) is one way for businesses to borrow accounts receivable, including, for example, accounts receivable by customers. The financing of the instrument may help the business improve cash flow, pay employees and suppliers, and may reinvest on operations and growth earlier than if the business had to wait until the customer paid the balance in full.

In some cases, a business may choose or may need to split a ticket financing. For example, if a business can only obtain a partial amount of the instrument financing noted on the instrument from a bank (i.e., less than the total amount), the business may attempt to obtain additional instrument financing from one or more other banks for some or all of the remaining amount. Banks involved in these situations may wish to ensure that financing they provide can be secured through the ticket. However, such banks have difficulty making such determinations because of the potential reluctance to share their financial information between banks.

Disclosure of Invention

In one aspect, a computer-implemented method for facilitating split-ticket financing includes: recording a public key ring, wherein the public key ring comprises a plurality of public keys of a plurality of users; recording a ticket token, the ticket token comprising an initial ticket value commitment of an initial ticket value; receiving a first transaction, the first transaction signed using the public key ring, the first transaction comprising a first loan commitment to a first loan value, a first updated instrument value commitment to a first updated instrument value, and a first range attestation to attest that the first loan value is less than or equal to the initial instrument value; and in response to determining that the first transaction is valid based on the first loan commitment, the first updated value commitment, and the first range attestation, replacing the initial value commitment to the ticket token record with the first updated value commitment.

In another aspect, an apparatus for facilitating split ticket financing comprises: one or more processors; one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to: recording a public key ring, wherein the public key ring comprises a plurality of public keys of a plurality of users; recording a ticket token, the ticket token comprising an initial ticket value commitment of an initial ticket value; receiving a first transaction, the first transaction signed using the public key ring, the first transaction comprising a first loan commitment for a first loan value, a first update instrument value commitment for a first update instrument value, and a first range attestation to certify that the first loan value is less than or equal to the initial instrument value; and in response to determining that the first transaction is valid based on the first loan commitment, the first updated value commitment, and the first range attestation, replacing the initial value commitment to the ticket token record with the first updated value commitment.

In yet another aspect, a non-transitory computer readable medium having stored therein instructions that, when executed by a processor of a device, cause the device to perform a method for facilitating split ticket financing. The method comprises the following steps: recording a public key ring, wherein the public key ring comprises a plurality of public keys of a plurality of users; recording a ticket token, the ticket token including an initial ticket value commitment to an initial ticket value; receiving a first transaction, the first transaction signed using the public key ring, the first transaction comprising a first loan commitment for a first loan value, a first update instrument value commitment for a first update instrument value, and a first range attestation to certify that the first loan value is less than or equal to the initial instrument value; and in response to determining that the first transaction is valid based on the first loan commitment, the first updated value commitment, and the first range attestation, replacing the initial value commitment to the ticket token record with the first updated value commitment.

Drawings

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

Fig. 1 is a schematic diagram of a blockchain system according to an embodiment.

Fig. 2 is a schematic diagram of a computing device for implementing nodes in a blockchain system, according to an embodiment.

Figure 3 is a flow diagram of a method for facilitating split ticket financing, according to an embodiment.

Fig. 4 is a flow diagram of a method for facilitating split ticket financing, according to an embodiment.

Figure 5 is a block diagram of an apparatus for facilitating split ticket financing according to an embodiment.

Detailed Description

Embodiments of the present specification provide methods and apparatus for facilitating split ticket financing. The method and apparatus may utilize a blockchain system to record a public key ring that contains public keys of a set of funds providers, including, for example, banks and other types of financial institutions. The method and apparatus may allow a user (e.g., a business, etc.) to request ticket financing from one or more funding providers. If the funds provider approves the user's request for a ticket financing, the funds provider may utilize the method and apparatus to submit a transaction to the blockchain system and record information regarding the still available amount of the ticket financing. In some embodiments, information regarding the still-available amount of a ticket financing may be represented by a commitment value. The method and apparatus may also allow a funds provider to sign a transaction using a public key ring. In this way, the method and apparatus may facilitate data sharing between the funds providers without requiring the funds providers to share their actual financial information with each other. Facilitating such data sharing may allow the funder to prevent the user from double financing, for example, by obtaining a ticket financing that exceeds the total amount noted on the ticket.

The embodiments disclosed in the specification have one or more technical effects. In some embodiments, the methods and apparatus utilize a blockchain system to record a public key ring that contains public keys of a set of funds providers. Thus, the method and apparatus may provide each of the funds providers in the group with the ability to sign transactions using a public key ring, effectively enabling the funds providers to hide their personal identity, which in turn helps the funds providers protect their financial information. In some embodiments, the methods and apparatus may also allow the funds provider to record a commitment value representing the still available amount of the instrument financing. Thus, the method and apparatus may provide a mechanism for a funder to update information about a financing of a ticket without sharing actual financial information between them with each other. In some embodiments, when a funder approves a user's instrument financing request, the funder may utilize the methods and apparatus to submit a transaction to the blockchain system and record information regarding the still available amount of instrument financing. Thus, the method and apparatus can record information and prevent double financing. In some embodiments, the method and apparatus may further perform zero knowledge range attestation. Thus, the method and apparatus can verify that no financing amount that has been issued by the fund provider exceeds the still available amount of the ticket financing, thereby further preventing double financing.

A blockchain system, also known as a Distributed Ledger System (DLS) or consensus system, can enable parties to store data securely and non-tamperproof. Without reference to any particular use case, the blockchain system may include any DLS and may be used for public, private, and federated blockchain networks. The public blockchain network is open to all entities to use the system and participate in the consensus process. The private blockchain network is provided for a specific entity which centrally controls read and write permissions. A federated blockchain network is provided for a selected group of entities that controls the consensus process, and includes an access control layer.

The blockchain system is implemented using a peer-to-peer (P2P) network in which nodes communicate directly with each other, e.g., without the need for a fixed central server. Each node in the P2P network may initiate communication with another node in the P2P network. The blockchain system maintains one or more blockchains.

Blockchains are data structures that store data, such as transactions, in a manner that prevents malicious parties from tampering with and manipulating the data. Transactions stored in this manner may be immutable and subsequently verified. A block chain includes one or more blocks. Each block is connected to the immediately preceding block by a cryptographic hash value (cryptographical hash) comprising the immediately preceding block. Each tile may also include a timestamp, its own cryptographic hash value, and one or more transactions. Transactions that have typically been verified by nodes of a blockchain system may be hashed and encoded into a data structure such as a merkel (Merkle) tree. In a merkel tree, data at leaf nodes of the tree is hashed, and all hash values in each branch of the tree may be joined at the root of that branch. This process continues down the tree until the root of the entire tree, where hash values representing all the data in the tree are stored. A hash value purporting to have a transaction stored in the tree can be quickly verified by determining whether it is consistent with the structure of the tree.

The blockchain system includes a network of computing nodes that manage, update, and maintain one or more blockchains. The network may be a public blockchain network, a private blockchain network, or a federated blockchain network. For example, many entities, such as hundreds, thousands, or even millions of entities, may operate in a public blockchain network, and each entity operates at least one node in the public blockchain network. Thus, a public blockchain network may be considered a public network with respect to participating entities. Sometimes, most entities (nodes) must sign each chunk in order for the chunk to be valid and added to the blockchain of a blockchain network. Exemplary public blockchain networks include peer-to-peer (peer-to-peer) payment networks that utilize distributed ledgers referred to as blockchains.

Typically, public blockchain networks may support open transactions. The open transaction is shared by all nodes within the public blockchain network and stored in the global blockchain. A global blockchain is a blockchain that is replicated across all nodes, and all nodes are in a fully-consensus state with respect to the global blockchain. To achieve consensus (e.g., agree to add blocks to a blockchain), a consensus protocol is implemented in a public blockchain network. Examples of consensus protocols include proof of work (POW) (e.g., implemented in some crypto-currency networks), proof of rights (POS), and proof of authority (POA).

Typically, a private blockchain network may be provided for a particular entity that centrally controls read and write permissions. The entity controls which nodes can participate in the blockchain network. Thus, private blockchain networks are often referred to as licensed networks, which limit who is allowed to participate in the network, as well as the extent to which they participate (e.g., only in certain transactions). Various types of access control mechanisms may be used (e.g., existing participants voting to add a new entity, and regulatory authorities may control admission).

Typically, a federated blockchain network is private between the participating entities. In a federated blockchain network, the consensus process is controlled by a set of authorized nodes, one or more of which are operated by respective entities (e.g., financial institutions, insurance companies). For example, a federation of ten (10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, and each entity may operate at least one node in the federated blockchain network. Thus, a federated blockchain network can be considered a private network with respect to participating entities. In some examples, each entity (node) must sign each chunk in order for the chunk to be valid and added to the chunk chain. In some examples, at least a subset of the entities (nodes) (e.g., at least 7 entities) must sign each chunk in order for the chunk to be valid and added to the chunk chain.

Fig. 1 shows a schematic diagram of a blockchain system 100 according to an embodiment. Referring to fig. 1, a blockchain system 100 may include a plurality of nodes, such as

nodes

102 and 110, configured to operate on a blockchain 120. Nodes 102-110 may form a network 112, such as a point-to-point (P2P) network. Each of

nodes

102 and 110 may be a computing device, such as a computer or computer system, configured to store a copy of block chain 120, or may be software, such as a process or application, running on the computing device. Each of the

nodes

102 and 110 may have a unique identifier.

Blockchain 120 may include a record growth list in the form of data chunks, such as chunks B1-B5 in fig. 1. Each of tiles B1-B5 may include a timestamp, a cryptographic hash value of a previous tile, and data of the current tile, which may be a transaction such as a monetary transaction. For example, as shown in fig. 1, chunk B5 may include a timestamp, a cryptographic hash value for chunk B4, and transaction data for chunk B5. Further, for example, a hash operation may be performed on a previous chunk to generate a cryptographic hash value for the previous chunk. The hash operation may convert inputs of various lengths into fixed-length encrypted outputs by a hash algorithm, such as SHA-256.

Node 102-110 may be configured to perform operations on blockchain 120. For example, when a node (e.g., node 102) wants to store new data onto blockchain 120, the node may generate a new block to be added to blockchain 120 and broadcast the new block to other nodes in network 112, such as

node

104 and 110. Based on the validity of the new tile, e.g., its signature and transaction validity, other nodes may determine to accept the new tile so that node 102 and other nodes may add the new tile to their respective copies of blockchain 120. As the process is repeated, more and more data blocks may be added to the block chain 120.

Fig. 2 illustrates a schematic diagram of a computing device 200 for implementing a node (e.g., node 102 (fig. 1)) in a blockchain system, according to an embodiment. Referring to fig. 2, computing device 200 may include a communication interface 202, a processor 204, and a memory 206.

The communication interface 202 may facilitate communication between the computing device 200 and devices implementing other nodes in a network, such as node 104 and 110 (FIG. 1). In some embodiments, communication interface 202 is configured to support one or more communication standards, such as an internet standard or protocol, an Integrated Services Digital Network (ISDN) standard, and so on. In some embodiments, the communication interface 202 may include one or more of the following: a 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, the communication interface 202 may be based on a public cloud infrastructure, a private cloud infrastructure, a hybrid public/private cloud infrastructure.

The processor 204 may include one or more special-purpose 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.

Memory 206 may store processor-executable instructions and data, such as a copy of block chain 120 (FIG. 1). The memory 206 may include any type or combination of volatile or non-volatile memory devices, 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 the instructions in memory 206 are executed by processor 204, computing device 200 may perform operations on blockchain 120.

Fig. 3 illustrates a flow diagram of a method 300 for facilitating split ticket financing, according to an embodiment. Referring to fig. 3, multiple users may own accounts on a blockchain, such as blockchain 120 (fig. 1). Blockchains may be implemented to support various types of users or parties, including, for example, individuals, businesses, banks, fund providers, financial institutions, hospitals, and other types of companies, organizations, and the like.

For illustration, a plurality of users including borrowers, managers, and a group of banks including, for example, banks 1 through N are depicted in FIG. 3. In some embodiments, each bank i of the group may have a public-private key pair(Pk _i ，Sk _i ) For signing transactions submitted to the blockchain. At step 302, each bank i may provide its public key Pk _i To the administrator, the administrator may generate a public key ring R at step 304 and submit the public key ring R to be recorded on the blockchain at step 306. In some embodiments, each bank i may provide its public key Pk _i Directly to the blockchain, the blockchain can generate and record a public key ring R.

In some embodiments, public key ring R may include a list of public keys, e.g., { Pk, received from a bank group ₁ ，Pk ₂ ，…，Pk _N }. In some embodiments, the blockchain may utilize one or more intelligent contracts executed on the blockchain to verify whether the public key contained in the public key ring R is valid. An intelligent contract is a computer protocol implemented in the form of computer code that is incorporated into a blockchain to facilitate, verify, or perform negotiation or fulfillment of a contract. For example, users of the blockchain may program agreed-upon terms into smart contracts using a programming language such as C + +, Java, Solidity, Python, etc., and when the terms are met, the smart contracts may be automatically executed in the blockchain, e.g., to perform transactions. As another example, an intelligent contract may comprise a plurality of subroutines or functions, each of which may be a series of program instructions that perform a specific task. An intelligent contract may be operational code that is executed without human interaction, in whole or in part.

In some embodiments, banks 1 through N may each record their public key Pk on the blockchain ₁ ，Pk ₂ ，…，Pk _N . In such embodiments, the blockchain may utilize one or more intelligent contracts to confirm that each public key contained in the public key ring R is recorded on the blockchain.

After the public key ring R is recorded on the blockchain, any member of the group, e.g., bank i ∈ 1 … N, may use the public key ring R along with its private key Sk _i The transaction is signed. For example, bank i may invoke signature method Sign () that will trade, private key Sk @ _i And a public key ring R as inputs and generates a ring signature σ as an output. If the signer (e.g. bank i) ownsPrivate key (e.g., private key Sk) _i ) The private key corresponds to one of the public keys in the public key ring R, and the signature method Sign () can generate a valid ring signature σ. Then, signature method Sign () may allow the use of public key ring R (instead of using bank i's public key Pk) _i ) The ring signature σ is generated in such a way that the validity of the ring signature σ is verified. In this way, bank i can hide its identity by signing the transaction using the ring signature σ. In other words, the transaction may appear to other users (including other banks of the group) to have been signed by members of the group. However, other users may not be able to determine which member of the group signed the transaction.

At step 308, a borrower interested in obtaining a ticket financing may generate a ticket token T for recording on the blockchain. The ticket token T may be generated based on the information of the ticket issued by the borrower. Such information may include, for example, the identity or identifier of the borrower, a product description or service description 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, and the like.

In some embodiments, the ticket token T may include a token identifier ID and a commitment value comm (v). The token identifier ID may represent an identifier that may be used to identify the ticket token T. The commitment value comm (v) may represent a commitment value for the total remaining value v of the instrument, which may represent remaining outstanding balances in the instrument that may still be used to obtain instrument financing in some embodiments. In some embodiments, the initial value of v may be set to the outstanding balance noted in the instrument, which may be the maximum amount that the borrower may use to obtain instrument financing. For ease of illustration, the maximum amount of money available to the borrower to obtain the financing of the instrument may be designated as max.

After determining the initial value of v, its commitment value comm (v) may be calculated based on the commitment scheme. The commitment scheme may include a cryptographic primitive that allows the borrower to commit the value of v while hiding the value of v from others. Thus, the borrower may only need to submit the commitment value comm (v) to the blockchain as part of the ticket token T, and thus may utilize this commitment value to prevent double financing. As described below, the blockchain may allow the borrower to borrow up to an initial value of v from a set of banks including bank 1 through bank N. However, if the blockchain determines that the borrower has borrowed to an initial value of v, the blockchain may refuse other borrowing attempts by the borrower using the same ticket.

In some embodiments, the commitment scheme used to calculate the commitment value comm (v) may be additively homomorphic, meaning that for a particular value x and a particular value y, the commitment scheme specifies

Equal to comm (x + y), where

Represents an algebraic operation (e.g., addition or multiplication) that may be performed on comm (x) and comm (y). In some embodiments, the commitment scheme used may be a Pedersen (Pedersen) commitment scheme, such as, for example, Torben Pryds Pedersen, disclosed in "Non-Interactive and Information-thermal Secure Verifiable Secret Sharing", Advances in cryptography- -CRYPTO 91 Procs, feature Notes in Computer Science, vol.576, pp.129-140, 1991, which is incorporated herein by reference in its entirety. The petersen commitment value for value v may be expressed as

Where PC () represents the Pedson commitment value, v represents the value used to calculate the Pedson commitment value, r _v Is a random number used to generate the peterson commitment value for value v, and g and h are generator values. The peterson commitment scheme is additive homomorphic, meaning that PC (x, r) _x )PC(y，r _y )＝PC(x+y，r _x +r _y )。

It should be understood that the peterson commitment described above is described by way of example only and is not meant to be limiting. It is contemplated that other commitment schemes may be used instead of or in addition to the peterson commitment. It should also be understood that the Pedeleson commitment value for v, in the above example denoted PC (v, r) _v ) But is just one example of the commitment value comm (v). Thus, it is possible to provideFor purposes of illustration, the following description may more generally refer to the commitment value of v as comm (v).

In some embodiments, the borrower may generate the ticket token T to include an optional data field d, which may include other information contained in the ticket. The data field d may include information relating to, for example, the identity or identifier of the borrower, a description of the product or service that the borrower provides to the purchaser, the identity or identifier of the purchaser, the payment terms, etc. In some embodiments, the data field d may be encrypted and, in some embodiments, may be included to meet regulatory agency audit requirements. In such embodiments, the data field d may be encrypted using the public key of the regulatory body.

In some embodiments, the borrower may sign the ticket token T using the borrower's private key. In some embodiments, the borrower may also request that the recipient of the ticket (e.g., a purchaser of the product or service provided) and/or a trusted entity (e.g., a government agency) sign the ticket token T with a respective private key to further prove the authenticity of the ticket. The borrower may submit the ticket token T to the blockchain.

At step 310, the blockchain may record the ticket token T submitted by the borrower. In some embodiments, the blockchain may require the borrower to provide a range of π proof to prove that the commitment value comm (v) contained in the ticket token T is calculated based on v, which is greater than 0 and less than or equal to the maximum amount of money that the borrower is allowed to borrow (i.e., 0 < v ≦ max). In some embodiments, the blockchain may refuse to record the ticket token T submitted by the borrower if the borrower fails to provide a satisfactory range credential of π. In some embodiments, blockchains may accept Range Proofs as zero knowledge Range Proofs, e.g., as disclosed by j.camenisch et al in "efficiency Protocols for Set Membership and Range profos," ASIACRYPT 2008, LNCS, vol.5350, pp.234-252, or b.bunz et al in "bulletprofos: short products for structural transformations and More ", IEEE Symposium on Security and Privacy, IEEE 2018, both of which are incorporated herein by reference in their entirety. It will be appreciated that accepting a zero knowledge range proof may allow the borrower to prove 0 < v ≦ max to the blockchain, but need not reveal the actual value of v to the blockchain. It is also to be understood that the zero knowledge range proof pi may be generated by various schemes including, but not limited to, the Bulletproof scheme, the Borromean Ring signature scheme, the Boneh-Boyen signature scheme, and the like. In this manner, the borrower may only need to disclose the commitment value comm (v) to the blockchain, which allows the borrower to keep the potential value of v private.

At step 312, the borrower may request a bill financing from a bank, such as bank 1. In some embodiments, the borrower may privately send information about the ticket and the ticket token T to the bank 1 through a down-link communication channel. Such information may include, for example, the token identifier ID of the ticket token T, the value of v, and the commitment scheme used by the borrower to calculate comm (v). If the borrower uses the peterson commitment to calculate comm (v), i.e., comm (v) ═ PC (v, r) _v ) The borrower may then provide r to the bank 1 _v The value of (c). The borrower may also send additional information to the bank 1 at will or upon request from the bank 1. Such additional information may include, for example, a description of the product or service provided, the identity or identifier of the purchaser, payment terms, etc. In some embodiments, the additional information may include information contained in the above-described data field d.

At step 314, the bank 1 may decide whether to offer the borrower a financial instrument. In some embodiments, the bank 1 may attempt to retrieve the ticket token T from the blockchain using a token identifier ID provided by the borrower. If the ticket token T cannot be retrieved, the bank 1 may refuse to process the borrower's request for ticket financing. If the ticket token T can be retrieved, the bank 1 may calculate comm (v) based on the value of v received at step 312 and compare the calculated comm (v) with the comm (v) recorded in the ticket token T. If the calculated comm (v) does not match the comm (v) recorded in the ticket token T, the bank 1 may refuse to proceed further, as the borrower may have changed _v The value of (c). Similarly, if the bank 1 has received additional information from the borrower, it includes the data contained in the data field dInformation, the bank 1 may encrypt the additional information received at step 312 and compare the encryption result with the encrypted data field d recorded in the ticket token T. If the encryption result calculated by the bank 1 does not match the encrypted data field d recorded in the ticket token T, the bank 1 may refuse to proceed further because the borrower may have changed the information contained in the data field d.

The bank 1 may also consider various other factors in determining whether to provide a financial instrument to the borrower. These factors may include, for example, the value of v, the amount of financing sought by the borrower, the credit score and credit history of the borrower, previous transactions by the bank 1 with the borrower, etc. Other factors may include, for example, the credit score of the buyer and the previous transactions of bank 1 with the buyer.

If the bank 1 decides to deny the borrower's request for bill financing, the bank 1 may privately communicate the decision to the borrower through a linked communication channel, in which case the borrower may choose to repeat step 312 and request bill financing from other banks. On the other hand, if the bank 1 decides to offer the borrower a bill financing for a particular loan amount, for example, a ₁ The bank 1 may communicate the decision to the borrower and generate a transaction to update the ticket token T recorded on the blockchain.

In some embodiments, the transaction generated by the bank 1 may include the token identifier ID of the ticket token T, the loan amount a ₁ Commitment value comm (a) ₁ ) And the total remaining value v of the bill updated _updated The commitment value comm (v) _updated ). In some embodiments, the bank 1 may make the loan by subtracting the loan amount a from the total remaining value v before issuing the loan ₁ To calculate v _updated I.e. v _updated ＝v-a ₁ 。

In some embodiments, the transaction generated by bank 1 may also include a range proof π for proving the loan amount a ₁ Greater than 0 and less than or equal to v (i.e., 0 < a) ₁ V is less than or equal to v). In some embodiments, bank 1 may generate range attestation pi as zero knowledge range attestation, whereby bank 1 may attest to the blockchain 0 <a ₁ V without revealing a to the blockchain ₁ The actual value of (c).

At step 316, the bank 1 may submit the transaction to the blockchain for recordation. For purposes of illustration, this transaction may be referred to as an UPDATE transaction. In some embodiments, bank 1 may sign the UPDATE transaction using a ring signature σ generated based on bank 1's private and public key rings R as described above. It should be noted that signing an UPDATE transaction using the ring signature σ can cause the bank 1 to hide its identity. In other words, bank 1 may 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.

At step 318, the blockchain may utilize the intelligent contract to verify the validity of the UPDATE transaction. In some embodiments, the smart contract may be based on a ring signature σ, a range attestation π contained in an UPDATED transaction, and a commitment value comm (a) ₁ ) And comm (v) _updated ) To verify the validity of the UPDATE transaction.

For example, in some embodiments, a smart contract may verify that the ring signature σ used to sign an UPDATE transaction is valid. In some embodiments, the smart contract may use public key ring R to verify the validity of ring signature σ. If the ring signature σ cannot be verified using the public key ring R, the smart contract can conclude that the bank 1 does not know the private key corresponding to one of the public keys in the public key ring R. Thus, the smart contract may conclude that bank 1 is not a member of the group that includes banks 1 through N. The smart contract may therefore consider the UPDATE transaction invalid and deny further progress.

Similarly, in some embodiments, a smart contract may determine whether the range proof contained in an UPDATE transaction is acceptable. If the smart contract determines that the range contained in the UPDATE transaction proves that π is unacceptable, e.g., the range proves that π does not prove 0 < a ₁ V ≦ the intelligent contract may consider the UPDATE transaction invalid and deny further progress.

The intelligent contract may also determine the commitment value comm (a) contained in the UPDATE transaction ₁ ) And comm(v _updated ) Whether it is acceptable. For example, the smart contract may retrieve the ticket token T from the blockchain using the token identifier ID contained in the UPDATE transaction. The intelligent contract may then retrieve the latest value of comm (v) recorded for the ticket token T and subtract ccomm (a) from comm (v) ₁ ) To calculate comm (v) -comm (a) ₁ ) (or comm (v)/comm (a) ₁ ) Depending on the homomorphic properties of the commitment scheme used). If comm (v) -comm (a) ₁ ) (or comm (v)/comm (a) ₁ ) The calculated value of (v) is compared with comm (v) contained in the UPDATE transaction _updated ) If the values of (a) do not match, the smart contract may consider the UPDATE transaction invalid and deny further progress. Otherwise, if comm (v) -comm (a) ₁ ) (or comm (v)/comm (a) ₁ ) The calculated value of (v) is compared with comm (v) contained in the UPDATE transaction _updated ) The intelligent contract can update the ticket token T and use the received comm (v) _updated ) Replaces the latest value of comm (v). In this way, comm (v) _updated ) Can be the latest value of comm (v) in the subsequent steps. Further, in this way, information about the total remaining value of the ticket can be verified and recorded on the blockchain without disclosing the actual total remaining value of the ticket to the public.

At step 320, the borrower may proceed to request the ticket financing from another bank, such as bank 2. In some embodiments, the borrower may privately send information about the ticket and the ticket token T to the bank 2 through a down-chain communication channel. Such information may include, for example, the token identifier ID of the ticket 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 after the ticket update. In other words, the loan amount a should now be subtracted from v ₁ Since it has already been used to obtain the loan issued by the bank 1. The borrower may also send additional information to the bank 2 on his own accord or on demand from the bank 2. Such additional information may include, for example, a description of the product or service provided by the borrower to the purchaser, the identity or identifier of the purchaser, payment terms, etc.

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

The bank 2 may also consider various other factors in determining whether to provide a financial instrument to the borrower. These factors may include, for example, the value of v, the amount of financing sought by the borrower, the credit score and credit history of the borrower, previous transactions by the bank 2 with the borrower, etc. Other factors may include, for example, the credit score of the purchaser and previous transactions with the purchaser by bank 2. In some embodiments, if the value of v has been set to zero, the bank 2 may deny the borrower's request for financing of the tickets, effectively preventing the borrower from double financing.

If the bank 2 decides to deny the borrower's request for financing on the tickets, the bank 2 may privately communicate the decision to the borrower through a chain-down communication channel, in which case the borrower may choose to repeat step 320 and request financing on the tickets from other banks. On the other hand, if the bank 2 decides to offer the borrower a bill financing for a particular loan amount, e.g., a ₂ The bank 2 may communicate the decision to the borrower and generate another UPDATE transaction to UPDATE the blockTicket token T recorded on the chain.

In some embodiments, the UPDATE transaction generated by the bank 2 may include the token identifier ID of the ticket token T, the loan amount a ₂ The commitment value comm (a) ₂ ) And the total remaining value v of the bill updated _updated The commitment value comm (v) _updated ). In some embodiments, the bank 2 may make the loan by subtracting the loan amount a from the total remaining value v before issuing the loan ₂ To calculate v _updated I.e. v _updated ＝v-a ₂ 。

In some embodiments, the transaction generated by bank 2 may also include a range attestation pi to attest to the loan amount a ₂ Greater than 0 and less than or equal to v (i.e., 0 < a) ₂ V is less than or equal to v). In some embodiments, bank 2 may generate a scope attestation pi as a zero knowledge scope attestation, whereby bank 2 may attest to the blockchain 0 < a ₂ V without revealing a to the blockchain ₂ The actual value of (c).

At step 324, bank 2 may submit the UPDATE transaction to the blockchain for recordation. In some embodiments, as described above, bank 2 may sign an UPDATE transaction using a ring signature σ generated based on bank 2's private and public key rings R. It should be noted that signing an UPDATE transaction using the ring signature σ can cause the bank 2 to hide its identity. In other words, bank 2 may simply identify itself as a member of the 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.

At step 326, the blockchain may utilize the intelligent contract to verify the validity of the UPDATE transaction. In some embodiments, the smart contract may be based on a ring signature σ, a range attestation π contained in an UPDATED transaction, and a commitment value comm (a) ₂ ) And comm (v) _updated ) To verify the validity of the UPDATE transaction.

For example, in some embodiments, a smart contract may verify that the ring signature σ used to sign an UPDATE transaction is valid. In some embodiments, the smart contract may verify the validity of the ring signature σ using public key ring R, and if the ring signature σ cannot be verified using public key ring R, the smart contract may consider the UPDATE transaction invalid and refuse to proceed further.

Similarly, in some embodiments, a smart contract may determine whether the range proof contained in an UPDATE transaction is acceptable. If the smart contract determines that the range contained in the UPDATE transaction proves that π is unacceptable, e.g., the range proves that π does not prove 0 < a ₂ V, the smart contract may consider the UPDATE transaction invalid and deny further progress.

The intelligent contract may also determine the commitment value comm (a) contained in the UPDATE transaction ₂ ) And comm (v) _updated ) Whether it is acceptable. For example, the smart contract may retrieve the ticket token T from the blockchain using the token identifier ID contained in the UPDATE transaction. The smart contract may then retrieve the latest value of comm (v) from the ticket token T and subtract comm (a) from comm (v) ₂ ) To calculate comm (v) -comm (a) ₂ ) The value of (c). If comm (v) -comm (a) ₂ ) With comm (v) contained in the UPDATE transaction _updated ) If the values of (a) do not match, the smart contract may consider the UPDATE transaction invalid and deny further progress. Otherwise, if comm (v) -comm (a) ₂ ) With comm (v) contained in the UPDATE transaction _updated ) The intelligent contract can update the ticket token T and use the received comm (v) _updated ) Replaces the latest value of comm (v). In this way, comm (v) _updated ) Can be the latest value of comm (v) in the subsequent steps. Further, in this way, information about the total remaining value of the ticket can be verified and recorded on the blockchain without disclosing the actual total remaining value of the ticket to the public.

It should be understood that steps 320 through 326 may be repeated, and that each time steps 320 through 326 are repeated, a new commitment value comm (v) may be calculated for the ticket token T _updated ) To replace the comm (v) recorded value. In this manner, the method 300 may allow the borrower to borrow an initial value v set by the borrower when the borrower initially generates the ticket token T, where 0 < v ≦ max. After the borrower has borrowed to the initial value v, the method 300 may refuse the borrower to use the ticketOther attempts to borrow token T.

Figure 4 illustrates a flow diagram of a method 400 for facilitating split ticket financing, according to an embodiment. The method 400 may be performed by one or more nodes in a blockchain system, such as node 102-110 in the blockchain system 100 (fig. 1).

Nodes

102 and 110 in block chain system 100 may perform operations on block chains, such as block chain 120 (fig. 1). Blockchain 120 may be implemented as a blockchain in the above example.

At 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 for multiple users. The users may include banks 1 to N, for example, as described above.

At step 404, node 102 may record a ticket token, such as ticket token T, on blockchain 120. The ticket token may be generated by a borrower (e.g., the borrower of fig. 3) from a ticket issued by the borrower. In some embodiments, the ticket token may include an initial ticket value commitment comm (v) of an initial ticket value v. In some embodiments, the initial ticket value v may be set to the outstanding balance noted in the ticket, which may be the maximum amount that the borrower may use to obtain the financing of the ticket. In some embodiments, the ticket token may also include an identifier and a data field. In some embodiments, the ticket token may be signed by the borrower using the borrower's private key. In some embodiments, the borrower may also request that the recipient and/or trusted entity of the ticket sign the ticket token using their respective private key to further prove the authenticity of the ticket. In some embodiments, the borrower may provide scope proofs to prove that the initial ticket value commitment comm (v) included in the ticket token is calculated based on an initial ticket value v, which is greater than 0 and less than or equal to a maximum amount of money the borrower is allowed to borrow. In some embodiments, the node 102 may record the ticket token on the blockchain 120 if the ticket token is properly signed and the range provided by the borrower proves acceptable.

At step 406, the node 102 may receive a first transaction, e.g., an UPDATE transaction received from bank 1 (fig. 3). The first transaction canTo include the first loan value a ₁ First loan commitment comm (a) ₁ ) Wherein the first loan value a ₁ The amount of financing of the instrument offered to the borrower may be determined on behalf of the bank 1. The first transaction may also include a first updated instrument value v _updated First update ticket value commitment comm (v) _updated ) Wherein the first updated ticket value v _updated May represent an updated value of v after the first loan was released. The first transaction may also include a first range attestation to attest to the value of the first loan a prior to the issuance of the first loan ₁ Less than or equal to the original ticket value v.

At step 408, node 102 may determine the validity of the first transaction and, in response to determining that the first transaction is valid, replace the initial ticket value commitment comm (v) recorded for the ticket token with the first updated ticket value commitment comm (v) _updated )。

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 plurality of users using a public key ring. If the first transaction is not signed by one of the plurality of users using the public key ring, node 102 may consider the first transaction invalid and deny further progress. In some embodiments, the node 102 may report an error if the node 102 considers the first transaction invalid.

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 contained in the first transaction proves unacceptable, e.g., the first range proves to fail to prove the first loan value a prior to issuing the loan ₁ Less than or equal to the initial ticket value v, the node 102 may consider the first transaction invalid and refuse to proceed further.

In some embodiments, the node 102 may also commit comm (v) based on the initial ticket value commitment, the first loan commitment comm (a) ₁ ) And the first update ticket value commitment comm (v) _updated ) Whether a predetermined algebraic relationship holds between to determine the validity of the first transaction. In some embodiments, the commitment may be calculated based on an additively homomorphic commitment scheme. In thatIn such an embodiment, the predetermined algebraic relationship may represent the initial value commitment comm (v) minus or divided by the first loan commitment comm (a) ₁ ) Should equal the first updated bill value commitment comm (v) _updated ). In this manner, if node 102 determines that the predetermined algebraic relationship between the initial value commitment, the first loan commitment and the first updated value commitment does not hold, node 102 may consider the first transaction invalid and refuse to proceed further. Otherwise, if the predetermined algebraic relationship holds, the node 102 may update the ticket token and commit comm (v) with the first updated ticket value _updated ) The initial ticket value commitment comm (v) recorded for the ticket token is replaced. In this way, comm (v) _updated ) May become the latest value of comm (v) in the subsequent steps.

At step 410, the node 102 may receive a second transaction, e.g., an UPDATE transaction received from bank 2 (fig. 3). The second transaction may include a second loan value a ₂ Second loan commitment comm (a) ₂ ) Wherein the second loan value a ₂ The amount of the financing of the instrument offered to the borrower may be determined on behalf of the bank 2. The second transaction may also include a second updated instrument value commitment of a second updated instrument value, wherein the second updated instrument value may represent an updated value of v after the second loan. The second transaction may also include a second range attestation to attest to a second loan value, a ₂ Less than or equal to the value of the first updated ticket before the second loan is issued.

At step 412, node 102 may determine the validity of the second transaction and, in response to determining that the second transaction is valid, replace the first updated instrument value commitment (i.e., the latest value of comm (v)) recorded for the instrument token with the second updated instrument value commitment. Node 102 may verify acceptability based on whether the second transaction was signed by one of the plurality of users using a public key ring, the range contained in the second transaction, or the first update ticket value commitment (now the latest value of comm (v)), the second loan commitment comm (a) ₂ ) And a second update ticket value commitment to determine the validity of the second transaction. If the predetermined algebraic relation holds, the node102 may update the ticket token and replace the value of comm (v) recorded for the ticket token with a second updated ticket value commitment. In this manner, the second UPDATE ticket value commitment may become the latest value of comm (v), and steps 410 and 412 may be repeated for another transaction, such as another UPDATE transaction received from another bank.

Fig. 5 is a block diagram of an apparatus 500 for facilitating split ticket financing, according to an embodiment. The apparatus 500 may be an implementation of a software process and may correspond to the method 400 (fig. 4). Referring to fig. 5, the apparatus 500 may include a receiving module 502, a determining module 504, a recording module 506, and a reporting module 508.

The receiving module 502 may receive public key rings submitted by one or more users, such as the administrators or banks 1 through N (fig. 3) described above. The public key ring may include multiple public keys for multiple users. The users may include, for example, banks 1 to N. The receiving module 502 may provide the received public key ring to the recording module 506, and the recording module 506 may record the received public key ring. The receiving module 502 may also receive a ticket token submitted by a borrower (e.g., the borrower of fig. 3) based on a ticket issued by the borrower. The receiving module 502 may provide the received ticket token to the recording module 506, and the recording module 506 may record the received ticket token. The receiving module 502 may also receive transactions submitted by one or more of a plurality of users, including, for example, banks 1 through N (fig. 3). The receiving module 502 may provide the received transaction to the determining module 504.

The determination module 504 may determine whether the transaction is valid. In some embodiments, the determination module 504 may determine whether the transaction is valid based on whether the transaction is signed by one of the plurality of users using a public key ring. In some embodiments, the determination module 504 may determine whether a transaction is valid based on whether the range certification contained in such transaction is acceptable. In some embodiments, the determination module 504 may determine whether a transaction is valid based on whether a predetermined algebraic relationship between certain commitment values contained in the transaction holds. In response to determining that the transaction is invalid, the determination module 504 may request the reporting module 508 to report an error. Otherwise, as described above, the determination module 504 may provide the transaction to the recording module 506, and the recording module 506 may record the transaction and update the recorded ticket token based on the transaction.

Each of the above modules may be implemented as software, or hardware, or a combination of software and hardware. For example, each of the above modules may be implemented using a processor, and the memory executes instructions stored in the memory. Also, for example, each of the above-described modules may 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, micro-controllers, microprocessors, or other electronic components to perform the described methods. Further, for example, each of the above-described modules may be implemented by using a computer chip or an entity, or by using a product having a specific function. In an embodiment, the apparatus 500 may be a computer, and the computer may 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 messaging device, a game console, a tablet, a wearable device, or any combination of these devices.

For the implementation of the functions and roles of each module in the apparatus 500, reference may be made to the corresponding steps in the above method. Details are omitted here for the sake of brevity.

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

The computer readable storage medium may be a tangible device that may store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, 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 coding device (e.g., a punch card or raised structure in a recess with instructions recorded thereon), and any suitable combination of the preceding.

The computer-readable program instructions for performing the methods described above may be assembler instructions, Instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including object oriented programming languages and conventional procedural programming languages. The computer-readable program instructions may execute entirely on the computing device as a stand-alone software package or execute partially on a first computing device and partially on a second computing device remote from the first computing device. In the latter case, the second remote computing device may be connected to the first computing device over any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN).

The 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 methods described above.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments herein. In this regard, the blocks in the flowchart or block diagrams may represent software programs, segments, or portions of code, which comprise one or more executable instructions for implementing the specified functions. It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the diagrams and/or flowchart illustration, and combinations of blocks in the diagrams and flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

It is appreciated that certain features of the disclosure, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the disclosure that are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination, or as suitable in any other described embodiment of the disclosure. Unless otherwise specified, certain features described in the context of various embodiments are not essential features of those embodiments.

While the present disclosure has been described in conjunction with specific embodiments, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, the following claims are intended to embrace all such alternatives, modifications and variances which fall within the scope of the claims.

Claims

1. A computer-implemented method for facilitating split instrument financing, the method comprising:

recording a public key ring, wherein the public key ring comprises a plurality of public keys of a plurality of users;

recording a ticket token, the ticket token including an initial ticket value commitment to an initial ticket value;

receiving a first transaction, the first transaction signed using the public key ring, the first transaction comprising a first loan commitment for a first loan value, a first update instrument value commitment for a first update instrument value, and a first range attestation to certify that the first loan value is less than or equal to the initial instrument value; and

in response to determining that the first transaction is valid based on the first loan commitment, the first updated instrument-value commitment, and the first range attestation, replacing the initial instrument-value commitment to the instrument token record with the first updated instrument-value commitment.

2. The method of claim 1, wherein the method is performed by one or more nodes in a blockchain system.

3. The method of any preceding claim, further comprising:

determining that the first transaction is valid when:

the first transaction is signed by one of the plurality of users using the public key ring,

said first range proves to be acceptable, an

A predetermined algebraic relationship holds between the initial value commitment, the first loan commitment and the first updated value commitment.

4. The method of claim 3, further comprising one of:

reporting an error in response to determining that the first transaction was not signed by one of the plurality of users using the public key ring;

reporting an error in response to determining that the first range attestation fails to demonstrate that the first loan value is less than or equal to the initial ticket value; or alternatively

Reporting an error in response to determining that the predetermined algebraic relationship between the initial value commitment, the first loan commitment and the first updated value commitment does not hold.

5. The method of any of claims 3-4, wherein the predetermined algebraic relationship represents the initial value commitment minus the first loan commitment equal to the first updated value commitment.

6. The method of any of claims 3-4, wherein the predetermined algebraic relationship represents the initial value commitment divided by the first loan commitment equal to the first updated value commitment.

7. A method according to any preceding claim, wherein the first range attestation is a zero knowledge range attestation proving that the first loan value is less than or equal to the initial instrument value without disclosing the first loan value.

8. The method according to any preceding claim, wherein the commitment is a peterson commitment.

9. The method of any preceding claim, further comprising:

receiving a second transaction, the second transaction signed using the public key ring, the second transaction comprising a second loan commitment for a second loan value, a second renewal instrument value commitment for a second renewal instrument value, and a second range attestation to certify that the second loan value is less than or equal to the first renewal instrument value; and

in response to determining that the second transaction is valid based on the second loan commitment, the second updated instrument value commitment, and the second range attestation, replacing the first updated instrument value commitment to the instrument token record with the second updated instrument value commitment.

10. The method of claim 9, further comprising:

determining that the second transaction is valid when:

the second transaction is signed by one of the plurality of users using the public key ring,

said second range proves to be acceptable, an

A predetermined algebraic relationship holds between the first updated value commitment, the second loan commitment and the second updated value commitment.

11. A method according to any of claims 9-10, wherein the second range attestation is a zero knowledge range attestation to attest that the second loan value is less than or equal to the first updated instrument value without disclosing the second loan value.

12. The method of any preceding claim, wherein the plurality of users comprises a plurality of instrument financing providers.

13. A computer-implemented apparatus for facilitating split ticket financing, comprising:

one or more processors; and

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

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

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