Privacy-preserving decentralized multi-party netting

1 . A method for a multi-lateral netting between parties, the method comprising:

collecting, by at least one hardware processor of each node related to each party of the parties independently, pending transactions between at least a part of the parties;

publishing, by the at least one hardware processor of each node related to each party of the parties, a commitment of a party-dependent total value of the pending transactions to a bulletin board, wherein the bulletin board is accessible by all the parties;

secretly sharing de-commitments among the parties, wherein each party-dependent de-commitment enables a verification to the party-dependent total value of the pending transactions as part of the commitment;

computing, using a multi-party computation protocol, a revised balance after the multi-lateral netting in a process configured to handle the pending transactions;

publishing, by the at least one hardware processor of each node related to each party of the parties, a determined liquidity status to the bulletin board;

upon determining a failure in the publishing, by the at least one hardware processor of each node related to each party of the parties, of the determined liquidity status, performing a secure fault-tolerant multi-party computation by determining whether all the pending transactions, regardless of an order of the pending transactions, are settable maintaining positive liquidity for each party of the parties;

upon determining a failure in determining whether all the pending transactions are nettable, determining, by the at least one hardware processor of each node related to each party of the parties, an optimized subset of transactions that are nettable without violating liquidity requirements for each party of the parties via a Karmarkar algorithm; and

determining, by the at least one hardware processor of each node related to each party of the parties, a secret share and a commitment of a new balance for each party of the parties.

2 . The method according to claim 1 , wherein the publishing, by each party of the parties, the determined liquidity status comprises determining, by the at least one hardware processor of each node related to each party of the parties, an own new liquidity amount using a current liquidity amount and verified party-dependent total amounts of the pending transactions via the bulletin board.

3 . The method according to claim 2 , further comprising publishing, by the at least one hardware processor of each node related to each party of the parties, a commitment of the own new liquidity amount.

4 . The method according to claim 1 , further comprising upon not settling all the pending transactions, in the multi-lateral netting, carrying over the not settled pending transactions for a next settlement cycle.

5 . The method according to claim 1 , wherein a transaction between the parties relates to one type fungible tokens or to more than one type of fungible tokens.

6 . The method according to claim 1 , wherein the secure fault-tolerant multi-party computation is performed by a sub-group of the parties.

7 . The method according to claim 1 , wherein the publishing, by the at least one hardware processor of each node related to each party of the parties, the determined liquidity status is based on a concept of a non-interactive zero-knowledge proof.

8 . The method according to claim 1 , wherein the determining, for each party of the parties, whether all the pending transactions are settable maintaining positive liquidity for each party of the parties comprises performing a netting among the parties.

9 . A system for a multi-lateral netting between parties, the system comprising:

a plurality of nodes, wherein each node related to a party of the parties, comprises a memory for storing program instructions, and a processor which, when executing the program instruction, is configured to:

collect independently pending transactions between at least a part of the parties;

publish a commitment of a party-dependent total value of the pending transactions to a bulletin board, wherein the bulletin board is accessible by all the parties;

secretly share de-commitments among the parties, wherein each party-dependent de-commitment enables a verification to the party-dependent total value of the pending transactions as part of the commitment;

compute, using a multi-party computation protocol, a revised balance after the multi-lateral netting in a process configured to handle the pending transactions;

publish a determined liquidity status to the bulletin board;

upon a determination of a failure in the publishing of the determined liquidity status, perform, using a subset of the plurality of nodes, a secure fault-tolerant multi-party computation by a determination of whether all the pending transactions, regardless of an order of the pending transactions, are settable maintaining positive liquidity for each party of the parties;

upon a determination of a failure in the determination of whether all the pending transactions are nettable, determine an optimized subset of transactions that are nettable without violation of liquidity requirements for each party of the parties via a Karmarkar algorithm; and

determine a secret share and a commitment of a new balance for each party of the parties.

10 . The system according to claim 9 , wherein the processor, when executing the program instruction, is further configured to:

during the publishing of the determined liquidity status, determine an own new liquidity amount using a current liquidity amount and verified party-dependent total amounts of the pending transactions via the bulletin board.

11 . The system according to claim 10 , wherein the processor, when executing the program instruction, is further configured to publish a commitment of the own new liquidity amount.

12 . The system according to claim 9 , wherein the processor, when executing the program instruction, is further configured to: upon not settling all the pending transactions, in the multi-lateral netting, carry over the not settled pending transactions for a next settlement cycle.

13 . The system according to claim 9 , wherein a transaction between the parties relates to one type fungible tokens or to more than one type of fungible tokens.

14 . A computer program product for a multi-lateral netting between parties, said computer program product comprising a computer readable storage medium having program instructions embodied therewith, said program instructions being executable by one or more computing systems to cause said one or more computing systems to:

collect independently pending transactions between at least a part of the parties;

publish a commitment of a party-dependent total value of the pending transactions to a bulletin board, wherein the bulletin board is accessible by all the parties;

secretly share de-commitments among the parties, wherein each party-dependent de-commitment enables a verification to the party-dependent total value of the pending transactions as part of the commitment;

compute, using a multi-party computation protocol, a revised balance after the multi-lateral netting in a process configured to handle the pending transactions;

publish a determined liquidity status to the bulletin board;

upon a determination of a failure in the publishing of the determined liquidity status, perform a secure fault-tolerant multi-party computation by a determination of whether all the pending transactions, regardless of an order of the pending transactions, are settable maintaining positive liquidity for each party of the parties;

upon a determination of a failure in the determination of whether all the pending transactions are nettable, determine an optimized subset of transactions that are nettable without violation of liquidity requirements for each party of the parties via a Karmarkar algorithm; and

determine a secret share and a commitment of a new balance for each party of the parties.