The term ‘secure fault-tolerant multi-party computation’—also known as secure computation, multi-party computation (MPC), or privacy-preserving computation—may denote a subfield of cryptography with the goal of creating methods for parties to jointly compute a function over their inputs while keeping those inputs private. Unlike traditional cryptographic tasks, where cryptography assures security and integrity of communication or storage and the adversary is outside the system of participants (an eavesdropper on the sender and receiver), the cryptography in this model protects participants' privacy from each other.—

This type of computation and protocol is about concealing partial information about data while computing with the data from many sources, and correctly producing outputs.

The term ‘zero knowledge proof’—or zero-knowledge protocol; in short: ZK—may denote in cryptography a method by which one party (the prover) may prove to another party (the verifier) that they know a value x, without conveying any information apart from the fact that they know the value x. The essence of zero-knowledge proofs is that it is trivial to prove that one possesses knowledge of certain information by simply revealing it; the challenge is to prove such possession without revealing the information itself or any additional information.

If proving a statement may require that the prover possesses some secret information, then the verifier will not be able to prove the statement to anyone else without possessing the secret information. The statement being proved must include the assertion that the prover may have such knowledge, but not the knowledge itself. Otherwise, the statement would not be proved in zero-knowledge because it provides the verifier with additional information about the statement by the end of the protocol. A zero-knowledge proof of knowledge is a special case when the statement consists only of the fact that the prover possesses the secret information.

‘Interactive zero-knowledge proofs’ may require interactions between the individual (or computer system) proving their knowledge and the individual validating the proof.

The term ‘non-interactive zero-knowledge proof’—also known as NIZK, zk-SNARK, zk-STARK—may denote and relate to the known concept of zero-knowledge proofs that may require no interaction between the prover and verifier.

Advantageously usable in the context of the here proposed concept is a non-interactive zero-knowledge scheme NiZKAoK. This may be instantiated using the known Schnorr NIZK. For range proofs specifically, one may also the known Bulletproofs in Fiat-Shamir mode.

The proposed method for a fully distributed privacy-preserving multi-lateral netting between parties may offer multiple advantages, technical effects, contributions and/or improvements:

The here proposed concept may describe a secure decentralized protocol that a consortium of local banks—or other institutions—may use to complete a netting process in a privacy-preserving manner without relying on a single central instance, e.g., a central bank. In order to achieve this advantageous goal, the concept makes use of two ingredients: zero-knowledge proofs and secure multiparty computation. Thereby, a multi-phase protocol may be constructed and its security can be proven.

Furthermore, a linear programming concept may be used to find an optimal solution to the netting problem in gridlock scenarios. In order to achieve this, the here proposed protocol may make use of MP-SPDZ (compare Marcel Keller, “A Versatile Framework of multi-party computation”, Cryptography eprint archive, report 2020/521, https://eprint.iacr.org/2020/521, 2020) and may achieve a 40% to 50% higher percentage settlement of the total transaction volume.

In contrast to existing solutions, a robust and fault-tolerant solution may be achieved which does not get stuck in case some parties abort the protocol. Furthermore, a maximum of confidentiality for the banks may also be achieved.

Additionally, the base protocol, or the optimistic phase used in normal situations where no bank runs out of liquidity is computationally comparatively low. Only in exceptional cases, the additionally possible multi-party computation portion of the protocol may have to be activated.

Furthermore, the distinct focus on “partial settlement” which may allow some fraction of a transaction to be processed (instead of “binary settlement”)—may enable to achieve even more efficient handling of gridlock scenarios. It was also possible to show that that concept proposed can achieve a settlement value that is up to 50% higher percentage than existing solutions.

The concept proposed here may free up computational resources on the part of a central bank for settlement between participating commercial banks as well as a single point of failure—i.e., the central bank—may be eliminated in the netting process.

The use of a bulletin board for sharing information—however in a non-completely disclosed form—using blockchain technology may also be judged to be an advantage of the here proposed concept. Blockchain technology is known as a reliable data platform for distributed ledgers. Again, these advantages may help support the trustworthiness of the concept proposed here.

Additionally, in the second portion of the here proposed protocol not all banks involved in the netting process have to participate in the multiparty computation but only a honest quorum of banks may be needed in order to achieve a netting between all participating banks, i.e., a settlement group.

In the following, additional embodiments of the inventive concept—applicable for the method as well as for the system—will be described.

According to a preferred embodiment, the method may comprise the publishing, by each party, its determined liquidity status may also comprise determining, by each party, its own new liquidity amount using its current liquidity amount and verified party-dependent total amounts of pending transactions via the bulletin board. The new liquidity amount may also be the base to determine the liquidity status. If the new liquidity amount >0 or larger than a predefined minimum amount, the liquidity status is determined to be positive, otherwise negative. The liquidity status may be published to the bulletin board in the form of a non-interactive zero-knowledge proof.

According to another preferred embodiment, the method may also comprise publishing, by each party, a commitment of its new liquidity amount. Thus, the bulletin board may comprise both, the current liquidity and a new liquidity amount, both in form of a commitment. Already here one may see that the amount of information on the bulletin board continues to grow from netting cycle to netting cycle.

According to one advanced embodiment, the method may also comprise, upon not settling all pending transactions in the multi-lateral settling, carrying over the not settled transactions for a next settlement cycle. This may be sometime later or during the next day in case the netting process typically happens once a day. Thus, no fungible tokens may be lost, only the settlement process may be partially deferred to a predetermined later point in time. Thus, the credibility of the proposed solution should not be in question.

According to a useful embodiment of the method, the determining an optimized subset—i.e., a maximum of netting value—of transactions may use a Karmarkar algorithm. Hence, the here proposed concept may easily make use of such proven concepts.

According to an advanced embodiment of the method, the bulletin board may be implemented as a blockchain. The bulletin board, i.e., the blockchain may be operated by a trusted sub-group of the parties or, alternatively, by a trusted institution which may not necessarily be the central bank. It may also be a commercial technology provider because not any clear-text data of the bulletin board may be shared anyway. Hence, also in this case, privacy may be preserved.

According to another enhanced embodiment of the method, a transaction between parties may relate to one type fungible tokens—e.g., Euros only—or to more than one type of fungible tokens, e.g., Euros and Dollars. Hence, the here proposed concept may also be able to perform the netting in different value categories at the same time, either in the optimistic phase of the protocol which may be relatively light-weight regarding required computing resources or in the MPC phase.

According to a further enhanced embodiment of the method, a pending transaction may be priority-flagged, wherein a related priority flag value is indicative of a priority for a settlement of the respective transaction. This may be especially useful in case of the MPC phase of the protocol in which typically not all amounts may be settled but only an optimized amount.

According to a permissive embodiment of the method, the secure fault-tolerant multi-party computation may be performed by a sub-group of the parties, e.g., an honest quorum of parties, or better by their respective computing nodes. This way, resources may be freed up at those parties not being part of the sub-group.

According to one advantageous embodiment of the method, the publishing, by each party, its liquidity status may be performed using the concept of a non-interactive zero-knowledge proof. This may be seen as a valuable aspect of the proposed concept and the ability to preserve privacy.

According to one further advantageous embodiment of the method, the portion of the method according to which all pending transactions are settable maintaining positive liquidity for each party may also comprise performing a netting among the parties. This would mark an end of a settlement cycle, either in the optimistic phase of the protocol or in the MPC phase.

In the following, a detailed description of the figures will be given. All instructions in the figures are schematic. Firstly, a block diagram of an embodiment of the inventive method for a fully distributed privacy-preserving multi-lateral netting between parties is given. Afterwards, further embodiments, as well as embodiments of the settlement system for a fully distributed privacy-preserving multi-lateral netting between parties will be described.

FIG. 1 shows a block diagram of a preferred embodiment of the method 100 for a fully distributed, i.e., decentralized, privacy-preserving multi-lateral netting between parties, e.g., a settlement group. The method 100 comprises collecting, 102, by each party independently, pending transactions between at least a part (or a portion) of the parties. The pending transactions relate to the ones needing settlement, e.g., to be transferred to another party or bank, i.e., the outgoing transactions of a party. The method may relate to all parties having theoretically fungible tokens to be netted. However, if some parties do not have anything to be settled, they may be excluded temporarily in the protocol, so that only a sub-group of the parties may perform the protocol.

The method 100 also comprises publishing, 104, by each party, a commitment of a party-dependent total value of pending transaction to a bulletin board as the commitment, wherein the bulletin board is accessible by all parties. This does not mean individual transactions that a party may have carried out for one of their clients, but the total volume of outgoing transactions. Additionally, to verify the value inside the commitment, a party would need a de-commitment.

Furthermore, the method 100 comprises secretly sharing, 106, de-commitments among the parties. Thereby, each party-dependent de-commitment enables a verification to the party-dependent total value of pending transactions as part of the related commitment, e.g., in order to verify the settlement amount or pending transaction for the specific party; i.e., only the addressed party can verify the individual settlement amount.

Moreover, the method 100 comprises publishing, 110, by each party, its determined, 108, liquidity status—which is a binary value—to the bulletin board. A negative liquidity status is not required to be published in NIZK form. The relevant party may choose to not publish the liquidity status. This would mean that the optimistic phase failed and the method enters the MPC phase.

I.e., upon determining, 112, a failure in the publishing, by each party, of any liquidity status, performing the following secure fault-tolerant multi-party computation. Hence, at least one party has not published its (positive) liquidity status or a timeout happened or any other failure like lost network connection or the like. At this point in time, the fallback procedure is initiated, i.e., the MPC phase. Otherwise, a commitment of the new liquidity amount is published (as commitment; not shown) to the bulletin board and the netting cycle closes.

This phase of the method 100 comprises determining, 114, whether all pending transactions are settable maintaining positive liquidity for each party (i.e., ignoring the partially already published new liquidity status). If that is the case, the netting process is executed.

If not, and upon determining that a failure in the determining, for each party, whether all pending transactions are nettable has happened, the method 100 comprises determining, 116, an optimized subset of transactions that are nettable without violating liquidity requirements for each party. This way, e.g., the maximum of netting value may be cleared during this cycle.

FIG. 2 shows a block diagram 200 of a 1^stportion of a more implementation-near embodiment of the inventive concept. The process starts with collecting and summing up, 202, pending outgoing transactions. In a next step, each of the participating parties may publish, 206, its initial liquidity L_ias a commitment—denoted here as C(L_i)—to the bulletin board which may be represented by the matrix 204. This example with three parties, three commitments of values or amounts of outgoing or pending transactions of party a, b, c, i.e., the commitments c(L_a), c(L_b), c(L_c), may be published.

In a next step, each party publishes, 208, to the bulletin board 204 party dependent commitments of total values of pending transactions in respect to other parties. Hence, the commitment c(t_ba) represents the total amount of outgoing or pending transactions from party b to party a.

However, without any de-commitment none of the values in the bulletin board 204—which may be implemented as a blockchain—is available in clear-text. In order to verify the commitments, partly by party, the parties secretly share, 210, the commitments among the parties, so that each party may verify its related commitment of the bulletin board 204.

With the information received and verified, each party is enabled to generate, 212, for itself a matrix of in- and outgoing amounts to other parties. Examples for the three parties are symbolized by the bracket 214 which is detailed for each of the parties in FIG. 4.

Based on this information of the individual matrices per party, each party can determine, 216, its new balance M and hence its liquidity status. Referring also to FIG. 4, the new balance for party a can be determined by M_a=L_a+t_ab+t_act_ca−t_ca. It is a straightforward determination wherein L_ais the current liquidity amount, t_ab+t_acare amounts to be received from other parties (namely, party b and c) and t_ba−t_caare amounts to be transferred from party a to by party b and party c. If M_a>0, the liquidity status would be positive, otherwise negative. Instead of a comparison to “zero”, also a comparison to a minimum amount of minimum liquidity may be made. The minimum liquidity amount may vary from party to party.

The process continues on FIG. 3 which shows a block diagram 300 of a 2^ndportion of the more implementation-near embodiment of the inventive concept. In case the liquidity of a party is not above zero—case “N” (compare determination 302)—the respective party may choose not to publish its liquidity status to the bulletin board 204. Hence, a fault 304 has happened in the optimistic phase.

In case the liquidity of the specific party is guaranteed—case “Y”—the respective party publishes, 306, its new liquidity status as non-interactive zero knowledge proofs (NIZK) to the bulletin board 204. Additionally, each party publishes, 308 also its new balance amount as a commitment c(M_a), c(M_b), c(M_c) to the bulletin board 204. The steps 306 and 308 may also be seen as the settlement 310 or the netting of the pending amount transactions. This also marks the end 312 of the optimistic phase.

However, in case a fault 304 has happened during the optimistic phase—i.e., no settlement process has been performed—the process continues on FIG. 5. The fault 304 may happen because one of the parties has not confirmed its liquidity by publishing its liquidity status in NIZK form or by a simple timeout, a network problem or any other error in this situation.

The following steps of the process of FIG. 5, which shows a block diagram 500 of a 3^rdportion of the more implementation-near embodiment of the inventive concept, are all performed in multi-party computing (MPC) mode. All parties of the settlement group may be involved in this MPC or only a sub-group, i.e., a quorum, of the parties can perform the MPC activities for all parties.

Firstly, a determination 502 is executed in order to determine of all pending transactions can be satisfied under the constraint that positive liquidity is maintained for all parties. If that is the case—case “Y”—the process continues with performing, 504—as described in the context of settling 310 in FIG. 3 (i.e., without using MPC)—a netting for all parties by determining local balances, commitments and local shares. Also the random number is updated, e.g., from r′ to s′.

The process or protocol of the actual cycle ends here, 510. At the beginning of the next netting cycle, the commitments are published, 512, to the bulletin board. Additionally, the secretly sharing the new balance among the parties is executed.

However, if the netting is not possible—case “N”—the process continues with determining, 506, an optimized subset of pending transactions that are nettable without violating liquidity requirements for each party. In order to determine the optimized subset, a plurality of different methods may be used, one of which may be there Karmardar method or algorithm.

Based on this result, the new secret shares and the commitments to the new balance of each party is determined by MPC (compare 508). Furthermore, the random numbers for the parties are also updated, e.g., from r′ to s′. Then the process would end, 510, identically if compared to the case in which a complete settlement could be achieved. Also here, the publishing 512 would happen at the start of the next cycle.

FIG. 4 shows a block diagram of intermediate matrices 400 used by the parties. Again, here an example of three parties is shown. Party a would be able to generate for itself matrix 402 to, party b would be able to generate for itself matrix 404 and, party c would be able to generate for itself matrix 406.

Each element in the matrix which one of the parties may verify and use for its further calculations (determining its consolidated new balance) comprises the commitment—e.g., [t_ab] t_abr_ab′ of the value of the sum of outgoing transactions from one of the parties, the respective clear-text, and a respective random value r_ab′ used for the value access. It may be noted that in each cycle—i.e., each new settlement process—a new random value—or better, a set of new random values—may be used. It may also be noted that the random values, e.g., r_ab′, may be pair-specific, i.e., each pair of parties party a/party b would use its own unique, single way random value r_ab′ which would be different to r_ba′.

During an initialization phase, each participating party may receive its random value from a central party, e.g., the central bank. It may also publish the commitments of the initial liquidity amounts to the bulletin board. However, this may only happen once and the central bank may no longer be required for an executing of the new proposed protocol. However, it may supervise the process.

FIG. 6 shows a block diagram of an embodiment of the settlement system for a fully distributed privacy-preserving multi-lateral netting between parties. The system comprises a plurality of nodes, wherein each node 600 relates to a party, wherein each node comprises a memory 602 for storing program instructions, and a processor 604 which, when executing the program instruction, is enabled to the following. However, it should be noted that the figure may show only units in modules of one of the nodes of a party.

The processor 604 may thus be enabled to collect—in particular, by a collection unit 606—independently pending transactions between at least a part of the parties, publish—in particular, by a publishing unit 608—a commitment of a party-dependent total value of pending transactions to a bulletin board, wherein the bulletin board is accessible by all parties, and secretly share—in particular, by a sharing unit 610—de-commitments among the parties, wherein each party-dependent de-commitment enables a verification to the party-dependent total value of pending transactions as part of the related commitment.

The processor 604 may thus also be enabled to publish—in particular by the publishing unit 608—its determined liquidity status to the bulletin board 204 (compare FIG. 2), and upon determining—in particular by a first determination unit 612—a failure in the publishing of any liquidity status, perform, using a subset of the plurality of nodes, the following secure fault-tolerant multi-party computation by determining—in particular by a second determination unit 614—whether all pending transactions are settable maintaining positive liquidity for each, and upon determining—in particular, by a third determination unit 616—a failure in the determining whether all pending transactions are nettable determining—in particular by a subset determination unit 618—an optimized subset of transactions that are nettable without violating liquidity requirements for each party.

It shall also be mentioned that all functional units, modules and functional blocks—namely, the memory 602, the processor 604, the collection unit 606, the publishing unit 608, the sharing unit 610, the first determination unit 612, the second determination unit 614, the third determination unit 616, and the subset determination unit 618—may be communicatively coupled to each other for signal or message exchange in a selected 1:1 manner. Alternatively the functional units, modules and functional blocks can also be linked to a node internal bus system 620 for a selective signal or message exchange.

Embodiments of the invention may be implemented together with virtually any type of computer, regardless of the platform being suitable for storing and/or executing program code. FIG. 7 shows, as an example, a computing system 700 suitable for executing program code related to the proposed method on one of the nodes 600.

The computing system 700 is only one example of a suitable computer system, and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the invention described herein, regardless, whether the computer system 700 is capable of being implemented and/or performing any of the functionality set forth hereinabove. In the computer system 700, there are components, which are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with computer system/server 700 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, and the like. Computer system/server 700 may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system 700. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computer system/server 700 may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both, local and remote computer system storage media, including memory storage devices.

As shown in the figure, computer system/server 700 is shown in the form of a general-purpose computing device. The components of computer system/server 700 may include, but are not limited to, one or more processors or processing units 702, a system memory 704, and a bus 706 that couple various system components including system memory 704 to the processor 702. Bus 706 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limiting, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnects (PCI) bus. Computer system/server 700 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system/server 700, and it includes both, volatile and non-volatile media, removable and non-removable media.

The system memory 704 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 708 and/or cache memory 710. Computer system/server 700 may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, a storage system 712 may be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a ‘hard drive’). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a ‘floppy disk’), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media may be provided. In such instances, each can be connected to bus 706 by one or more data media interfaces. As will be further depicted and described below, memory 704 may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention.

The program/utility, having a set (at least one) of program modules 716, may be stored in memory 704 by way of example, and not limiting, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating systems, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules 716 generally carry out the functions and/or methodologies of embodiments of the invention, as described herein.

The computer system/server 700 may also communicate with one or more external devices 718 such as a keyboard, a pointing device, a display 720, etc.; one or more devices that enable a user to interact with computer system/server 700; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server 700 to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces 714. Still yet, computer system/server 700 may communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter 722. As depicted, network adapter 722 may communicate with the other components of the computer system/server 700 via bus 706. It should be understood that, although not shown, other hardware and/or software components could be used in conjunction with computer system/server 700. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.