WO2019150132A1

WO2019150132A1 - Secure, distributed futures market exchange

Info

Publication number: WO2019150132A1
Application number: PCT/GB2019/050293
Authority: WO
Inventors: Fabio Massacci; Ngo Chan NAM; Jing NIE; Julian WILLIAMS
Original assignee: University Of Durham
Priority date: 2018-02-02
Filing date: 2019-02-04
Publication date: 2019-08-08
Also published as: GB201801761D0

Abstract

A secure transaction system for a plurality of users, comprising a network comprising a plurality of nodes; a plurality of user devices, each user device associated with a respective user and each located at a respective one of the nodes; a plurality of private ledgers, a public ledger that stores public data. At least some of the public data and at least some of the private data of the users are mutually dependent. Each user device is configured to perform a cryptographic process in dependence on data from its associated private ledger and data from the public ledger to generate cryptographically secure data item(s) that are processable by the other user devices to determine a property of the user and/or a transaction that the user desires or is offering to perform or has performed. The cryptographic process is such that the cryptographically secure data item(s) is verifiable by the other user devices without determining values of at least some of the data of the private ledger of the user and/or without determining the identity of the user.

Description

SECURE, DISTRIBUTED FUTURES MARKET EXCHANGE

Introduction

The present invention relates to a secure transaction system, for example a secure transaction system operable to provide a market for the trading of assets by a plurality of users.

Background

Secure transaction systems come in a wide variety of types. In some cases it is necessary or desired to maintain anonymity of participants who use the system and/or to maintain secret some or all of the information relating to such participants.

The maintenance of anonymity and/or confidentiality can be particularly important in, for example, secure transaction systems for double-auction type markets or any other types of markets in which knowledge of the identity and/or properties of a participant (for example, their financial positon or their trading activity) can lead to unfair or undesired trading strategies by other parties, or can lead to participants being exposed to undesired levels of risk.

Centralized exchanges have traditionally been used to administer certain types of market. Examples of such centralized exchanges are discussed in section I of the description section below. Typically such centralized exchanges maintain the anonymity of market participants and the confidentiality of their information, whilst also applying rules and procedures (for example, maintenance of margin accounts, application of settlement rules and mark-to- market procedures) to ensure that market participants are able to fulfil their commitments, thus reducing risks to other market participants.

However, centralized exchanges impose a high technical and administrative burden with complex regulatory and governance requirements and complex technical infrastructures. There can be high barriers to entry both for participants in such markets and in relation to the establishment of new centralized exchanges.

There have been rapid developments in recent years in technologies that provide for secure exchange of information over networks, for example over the internet. There have also been developments in distributed ledger technologies that replace or augment centrally maintained data stores with shared storage of data across multiple sites, and which for example rely on consensus amongst multiple users to ensure that the stored data is correct. The user of distributed ledger technologies can ensure that stored data is robust against fraud and cyber- attack even in the absence of a secure centrally administered data store. However, the use of such distributed ledger technologies can be problematic in rapidly changing transactional situations where it is also desired to maintain anonymity and confidentiality of participants whilst at the same time ensuring that participants can reliably carry out transactions to which they have committed.

In a Futures-Exchange, such as the Chicago Mercantile Exchange, traders buy and sell contractual promises (futures) to acquire or deliver, at some future pre-specified date, assets ranging from wheat to crude oil and from bacon to cash in a desired currency. The interactions between economic and security properties and the exchange's essentially non-monotonic security behavior; a valid trader's, valid action can invalidate other traders' previously valid positions, are a challenge for security research.

For the last two decades, many inventions of the financial markets, listed in the U.S. patent applications, show quite consistent goals to have a rapidly, accurately and secured trading system surrounding a central exchange. Most patents related to the futures markets are generally directed to automated trading systems or electronic trading exchanges [64], [15], [29], [32], [46].

For instance, in 1990, Wagner [64] put forward the Automated futures trading exchange, the U.S. Patent No. US4903201 , which provides a computerized system for the open outcry future trading exchanges. Traders submit bids and asks orders through their remote terminals to the computerized exchange system. The computerized central processor automatically receives orders and couple bids and asks to find a match based on the first-come, first-served basis to complete a transaction. The main purpose of this patent is to build an automated trading system and exchange to allow a large amount of traders remotely submitting orders with dynamic volume to the central processor.

As the early stage of the automated trading system, Wagner's patent is invented for the open outcry platform; whereas, these days the futures contracts are traded on the electronic trading platform. The patents related to the futures markets are more specific to the electronic trading exchange. For instance, the Automated trading system in an electronic trading exchange, the U.S. Patent No. US8725621 , submitted by Marynowski et al. [46]. This patent implements an advanced electronic exchange system to have the ability to rapidly capture effective orders and respond to the potential trading opportunities. It also attempts to enhance the accuracy of automatic trading actions and provide a remotely controlled traders station. The traditional trading network contains two parts, traders sites and exchange sites. This patent adds an automated trading system in the traders sites, which includes a receiver interface, a data reference logic, a decision logic and an output interface. Before an order goes to the exchange site, it will be assessed through the automated trading system based on the market prices of underlying assets and the theoretical prediction (a look-up table) of buying or selling prices.

Hence, the automated trading system can assist traders to check the accuracy of trading decisions and to reduce the transaction risks. Network: [15] Network and Method for Trading Derivatives, the Patent No. US 7337140, provides a computer network and method invention in the field of electronically trading derivatives.

The system includes networks and methods where a control or network managing station in the network acts as a facilitator for the market makers and subscribers to make a trade at an Exchange. In another embodiment the network managing station consummates the trade between a market maker and a subscriber by matching binding quotes and orders and clears the trade at an Exchange. The computer network for electronically trading derivative comprises: (a) network managing station; (b) one or more market maker stations; (c) one or more subscriber stations; (d) one or more Exchanges. The network managing station connects market makers and subscribers for making real time indicative quotes, issuing requests for quotes, obtaining binding quotes and wherein the market maker and subscriber are in communication with an Exchange for sending binding quotes and orders to the Exchange for clearing and confirming transactions. There are some patents focusing on enhancing the speed and accuracy of the trading message dissemination in an electronic trading exchange [51], [41].

Further discussion of the background is provided in some parts of the description section below. Summary

In a first, independent, aspect there is provided a secure transaction system for a plurality of users, comprising

a network comprising a plurality of nodes;

a plurality of user devices, each user device associated with a respective user and each located at a respective one of the nodes;

a plurality of private ledgers, each private ledger being stored at or accessible by a respective one of the user devices and containing private data associated with the corresponding user;

a public ledger that stores public data, wherein the public data is representative of, or is processable, to determine, transactions that are available to users;

wherein at least some of the public data and at least some of the private data of the users are mutually dependent, such that a change in said at least some of the public data affects correct value(s) for at least some of the private data and such that a change of said at least some of the private data affects correct value(s) for said at least some of the public data;

each user device is configured to perform a cryptographic process in dependence on data from its associated private ledger and data from the public ledger to generate cryptographically secure data item(s) that are processable by the other user devices to determine a property of the user and/or a transaction that the user desires or is offering to perform or has performed;

wherein the cryptographic process is such that the cryptographically secure data item(s) is verifiable by the other user devices without determining values of at least some, optionally any, of the data of the private ledger of the user and/or without determining the identity of the user.

The public data may comprise data to which all of the users are permitted access. The public data may comprise, or be representative of, or be obtained by processing, data obtained from a plurality of the users. The public data may comprise or be representative of an aggregation of data from a plurality of the user devices.

The cryptographically secure data item(s) may comprise certified data item(s). The verifying of the cryptographically secure data item(s) by the other user devices may comprise decrypting the cryptographically secure data item(s). The verifying of the cryptographically secure data item(s) by the other user devices may comprise determining that the data item(s) are valid (for example, up-to-date, not interfered with or corrupted by a third party, consistent with the public ledger and/or private ledgers accessible to the other user devices). The verifying of the cryptographically secure data item(s) by the other user devices may comprise determining that the data item(s) are valid in accordance with a cryptographic protocol.

The cryptographically secure data item(s) may verifiable by the other user devices without determining values of at least some of the data of the private ledger of the user that was used to generate the secure data item(s) and/or without determining the identity of the user.

The cryptographically secure data item(s) may be processable by the other user devices to determine, for example, a commitment and/or a buy or sell order, for instance without determining from which user or user device the commitment and/or buy or sell order originated and without revealing other commitments and/or buy or sell orders issued by the user or user device and without revealing a status of at least one

The secure data item(s) may be such that user identity or user device identity is not determinable by the other user devices by processing the cryptographically secure data item(s) generated by the user device.

Each cryptographically secure data items may comprise a zero knowledge proof, optionally a non-interactive zero knowledge (NZK) proof.

The encryption process may be such that if the transaction that is desired or being offered by the user is not valid, for example based on a status of the user, then the cryptographic process will fail.

The encryption process may be such that if the version of the public ledger that the user device bases the encryption process upon is different to a version of the public ledger used by another of the user devices then said other of the user devices the cryptographically secure data item will be rejected or determined to be invalid by said other of the user devices.

The encryption process may be such that if the transaction that is desired or being offered by the user is not valid, for example based on a status of the user, then the corresponding cryptographically secure data item(s) is processable by the other user device(s) to determine that the transaction is invalid and/or is such as to be rejected by the other user devices.

The public ledger and/or multiple versions of the public ledger may be stored jointly or separately by, or under control of, the plurality of user devices.

The public ledger may comprise a distributed ledger.

The public ledger comprises a block chain-based distributed ledger.

The user devices may be configured to, in response to a cryptographically secure data item(s) from another of the user devices determine that the cryptographically secure data item(s) represent a valid transaction and update the public ledger with said valid transaction.

The plurality of user devices may be configured to distribute public ledger updates thereby to maintain up-to-date version(s) of the public ledger. For example, each user device may be configured to distribute public ledger updates and/or its current version of the public ledger to at least some, optionally substantially all, of the other user devices.

The transactions comprise at least one of a buy order, a sell order.

The transactions may comprise transactions performed in respect of at least one asset or a derivative thereof, optionally a financial instrument, optionally at least one of a futures contract, an option, a swap, or other derivative.

The asset(s) may comprise at least one of a stock, bond, currency, physical asset or a financial instrument derived therefrom.

The transaction system may be operable to provide a market, and the users may comprise market participants. The users may comprise traders and the user devices may be configured to perform trades with respect to the market. The users may comprise natural or legal entities, for example people, or may comprise financial trading accounts or trading machines configured to trade automatically, for example algorithmic trading devices. There may be more than one of the user devices associated with a single user. For example a user may have multiple trading accounts each having a corresponding user device. Alternatively, a user device may be used to trade in respect of a plurality of users or a plurality of different trading accounts associated with a particular user. Optionally more than one of the user devices may be located at a single one of the nodes.

The public ledger may comprise a representation of a state of the market, optionally a current state of the market.

The public ledger may comprise a representation of a collection of transactions proposed, variously, by or otherwise associated with a plurality of the users, optionally all of the users.

The public ledger may comprise or be representative of or be processable to determine transactions available to the users.

Each user device may be configured to perform a transaction and to update the public ledger and its private ledger in view of the transaction.

Each user device may be configured to transmit a message, for example to the other devices and/or over the network, representative of the transaction and/or representative of a state of the market after the transaction. The message may comprise or be processable to perform a public-ledger update. Each user device may be configured to update its version of the public ledger in response to messages from other users.

The user devices may be configured to transmit messages and/or data and/or ledger updates in the form of blocks according to block-chain protocol.

Each user device may store or be associated with at least one of a financial account, a margin account, an asset holding account or other account. Each user device may be configured to update at least one of its associated account(s) in response to performance of a transaction. Each user device may be configured to update at least one of its associated account(s) in accordance with at least one market rule.

The cryptographic process may be such that, and/or the user device may be configured to apply market rules such that, generation of the cryptographically secure data item(s) in respect of a transaction desired by a user may be rejected or prevented or otherwise not allowed by the user device if the transaction would be against a market rule and/or would cause at least one of the account(s) to fall below a pre-determined threshold amount and/or would cause a user to pass through a pre-determined risk management threshold.

Each user device may comprise a processing resource, for example a processor, and may comprise or form part of for example a personal computer, laptop, mobile phone, smart phone or other mobile or fixed computing device. Each user device may comprise a network interface for transmitting and/or receiving data to and/or from the other user devices either directly or indirectly, optionally via the network.

In a further aspect, which may be provided independently, there is provided a device for performing secure transactions comprising a processing resource and a communication interface for communicating with at least one further device, optionally a plurality of further devices, for example via a network. The device may comprise, and/or the processing device may be configured to communicate with, at least one data store.

The at least one data store may store a private ledger containing private data associated with a user. The at least one data store may store public data, wherein the public data may be representative of, or processable, to determine, transactions that are available to users. At least some of the public data and at least some of the private data of the users may be mutually dependent, such that a change in said at least some of the public data affects correct value(s) for at least some of the private data and such that a change of said at least some of the private data affects correct value(s) for said at least some of the publicdata.

The processing resource configured to perform a cryptographic process in dependence on data from its associated private ledger and data from the public ledger to generate cryptographically secure data item(s) that are processable by other user devices to determine a property of the user and/or a transaction that the user desires or is offering to perform or has performed.

The cryptographic process may be such that the cryptographically secure data item(s) is verifiable by the other user devices without determining values of at least some, optionally any, of the data of the private ledger of the user and/or without determining the identity of the user. The processing resource of the device may be configured to receive a cryptographically secure data item(s) from at least one other user device and to process said cryptographically secure data item(s) to determine a property of another user (for example a user associated with said at least one other device) and/or a transaction that said another user desires or is offering to perform or has performed.

In a further aspect there is a provided a system comprising a plurality of user devices according to any other aspect, and a network configured to provide communication between said plurality of user devices.

In a further aspect, which may be provided independently, there is provided a method for performing a secure transaction comprising performing a cryptographic process in dependence on data from a private ledger associated with a user and data from a public ledger to generate cryptographically secure data item(s) that are processable by other users devices to determine a property of the user and/or a transaction that the user desires or is offering to perform or has performed. At least some of the public data and at least some of the private data of the users may be mutually dependent, such that a change in said at least some of the public data affects correct value(s) for at least some of the private data and such that a change of said at least some of the private data affects correct value(s) for said at least some of the public data.

In a further aspect, which may be provided independently, there is provided a method for performing a secure transaction comprising receive a cryptographically secure data item(s) 30 associated with a user and processing said cryptographically secure data item(s) to determine a property of said user and/or a transaction that said another user desire or is offering to perform or has performed.

In a further aspect or aspects, there is provided a computer program product comprising computer readable instructions that are executable by a processor to perform a method according to any aspect or embodiment described herein.

In a further aspect, which may be provided independently, there is provided a method and apparatus for the distributed, privacy preserving and integrity preserving technical implementation of an order book where a group of computing devices belonging to agents (e.g. traders, brokers, or groups thereof) wishing to engage in distributed double auctions and markets can

1) keep private the information about the solvency of the individual agent owing the trader's computer

and/or

2) publicly register the values of buy and sell orders while

a) maintaining confidential the information about the owner of the buy (resp. sell) order b) and still having the possibility to accrue matched buy/sell transactions to the accounts of the computing devices of the individual agents owing those orders

and/or

3) maintain the financial integrity of the market as implemented by a distributed system of computing devices so that only computing devices operated by solvent agents can participate in the buy/sell bids

and/or

4) keep private the possible exit from the market by computing devices operated by agents who could no longer meet their contractual obligations due to bids by computing devices owned by other agents leading to market fluctuations.

Computing devices owned by agents who infrequently make bids may be requested or required to participate in the transactions to control the market risk but not to participate with full-fledged multi-party computation for every single step.

In another aspect, which may be provided independently, there is provided a distributed order book system, wherein confidential information about a trader's position (e.g. one or more of margin, posted orders, etc.) is stored privately at a trader's own device; and commitment of the information is stored publicly, for example on a ledger accessible to all trader's devices or individually by each of the traders.

In a further aspect, which may be provided independently, there is provided a system comprising a network of trader devices. In another aspect, which may be provided independently, there is provided a trader device, which may form part of the network of the immediately preceding aspect. The or each trader device may comprise at least one, optionally all, of the following:

a) a network module in a trader device to send a certified piece of data representing a non-interactive proof;

b) a processing module coupled to the network module in the trader's device;

c) a storage module coupled with the processing module to store private confidential information about the distributed ledger;

d) a random generator module to generate cryptographically strong random numbers; e) an encryption and proof generation module that use the random generator module to generate the certified piece of data representing a non-interactive zero-knowledge NZK proof; f) a commitment module that use the random generator module to augment the piece of data so that the resulting generation of the module is a piece of data representing the commitment to trader's private information while being disassociated from the actual content of the piece of data to be used in the non-interactive proof which could be implemented but not limited to by an hash function;

g) a verifier module to check the received piece of data corresponding to the non- interactive proof from other trader devices;

h) an MPC module that use the random generator module to privately compute a global function's output with other trader devices regarding the trader device's secret input.

The network adapter may be configured to broadcast the non-interactive proof of a piece of data to the other node possibly by writing to a distributed ledger, for example by adding a ledger module to each trader device.

The network adapter may be configured to broadcast anonymously an order and the non- interactive proof of a piece of data to the other node possibly by using an anonymous network.

The processing module may have access to a possibly different storage module either directly or indirectly through the network interface to retrieve or store information about the public part of the distributed order book.

In a further aspect, which may be provided independently, there is provided a method to operate a distributed apparatus, optionally according to any aspect or embodiment as described herein, wherein each state of Figure 1 is implemented by using a suitable combination of NZK and MPC, for example as summarized in Figure 3. The method or system may be configured or configurable to scale to a larger number of trader devices to make it suitable for practical futures exchanges

The method or system may be configured so that trader devices which fail, for example for arbitrary reasons, can be penalized.

In another aspect of the invention, which may be provided independently, there is provided a computer program product comprising computer readable instructions that are executable by a processor or processors to perform a method as claimed or described herein.

There may be provided a method, system or device substantially as described herein with reference to the accompanying drawings.

In a further aspect of the invention, which may be provided independently, there is provided a secure, fully distributed Futures-Exchange. A distributed, asynchronous protocol may simulate the centralized functionality under the assumptions of anonymity of the physical layer and availability of a distributed ledger. Security with abort (in absence of honest majority) may be considered and may be extended to penalties. The implementation and its optimization (based on zk-SNARKs and SPDZ) may demonstrate that the computation of actual trading days (along Thomson-Reuters Tick History DB) may be feasible for low-frequency markets. The security properties may be shown that guarantee an Exchange's economic viability (availability of trading information, liquidity, confidentiality of positions, absence of price discrimination, risk management) and an attack when traders' anonymity is broken.

Features in one aspect may be provided as features in any other aspect as appropriate. For example, features of a method may be provided as features of an apparatus and vice versa. Any feature or features in one aspect may be provided in combination with any suitable feature or features in any other aspect.

Brief description of the drawings

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying schematic drawings, in which: Figure 1 depicts a Market State Transition Diagram of a Centralized Exchange (Simplified); Figure 2 depicts a diagram of a Distributed Network in accordance with an embodiment of the invention;

Figure 3 depicts a diagram of Proposed Protocols and Methods to Implement the General State Diagram Functionalities from Figure 1 with a Fair Computational Load for Traders Infrequently Making Bids in accordance with an embodiment of the invention;

Figure 4 depicts a diagram of Fields of the PRIVATE TRADER STATUS BOOK in accordance with an embodiment of the invention;

Figure 5 depicts an Authorized Inventory flags state transition diagram in accordance with an embodiment of the invention;

Figure 6 depicts a diagram of Fields of the PRIVATE INVENTORY BOOK in accordance with an embodiment of the invention;

Figure 7 depicts a diagram of a Virtual PRIVATE ORDER BOOK at time t in accordance with an embodiment of the invention;

Figure 8 depicts a diagram of the Construction of Commitment Relations from Table VIII in accordance with an embodiment of the invention;

Figure 9 depicts a diagram of Non-interactive Zero Knowledge Computation Steps ZK Across Trader Devices in accordance with an embodiment of the invention;

Figure 10 depicts a diagram of Trader Device Computation for τβ] piece of data in accordance with an embodiment of the invention;

Figure 11 depicts a diagram of an Order Book in accordance with an embodiment of the invention;

Figure 12 depicts a diagram of the operations of the ideal functionality FCFM for posting, cancelling and marking to market;

Figure 13 depicts a diagram of the operations of the ideal functionality F_CFM for margin settlement and order fulfillment;

Figure 14 depicts an inventory flags state transition diagram in accordance with an embodiment of the invention;

Figure 15 depicts a diagram of Hybrid Implementation of the Ideal Functionality in accordance with an embodiment of the invention;

Figure 16 depicts a diagram of sub-protocols n_MH, ΓΊη*, Ππ*** and nb«*u> in accordance with an embodiment of the invention;

Figure 17 depicts a diagram of Crypto Protocol Evaluation on Q1 of Lean-Hog in accordance with an embodiment of the invention;

Figure 18 depicts a diagram of Total Burden of Computation by Retail Traders in accordance with an embodiment of the invention;

Figure 19 depicts a diagram of sub-protocols Πρ^ and rig* in accordance with an embodiment of the invention;

Figure 20 depicts a diagram of the protocol Πο™ in accordance with an embodiment of the invention.

Description

Various embodiments will now be described by way of example only, and with reference to the accompanying drawings.

Certain embodiments are described as being implemented as devices, for example trader or user devices. Such devices may be implemented as any suitable combination of hardware and/or software. For example, according to embodiments each device may be implemented as a computing apparatus that provides a processing resource for receiving, processing and or storing data. Such computing apparatus may comprise a central processing unit (CPU) that is operable to load and execute a variety of software modules or other software components. The computing apparatus may also include a hard drive and other components including RAM, ROM, a data bus, an operating system including various device drivers, and hardware devices including a graphics card. Such components are not shown in the figures for clarity.

Certain embodiments also include network interfaces to enable devices to communicate and/or transmit data over a network. Any suitable network interface and network may be used. For example, the network may comprise a wired or wireless network, and may be in whole or part a private or public network. At least part of the network may comprise internet connections.

Whilst particular modules are described herein in relation to certain embodiments, in alternative embodiments functionality of a plurality of modules can be provided by a single processing resource, device or other component, or functionality provided by a single module can be provided by two or more devices, processing resources or other components in combination. Reference to a single module encompasses multiple components providing the functionality of that module in alternative embodiments, whether or not such components are remote from one another, and reference to multiple modules encompasses a single component providing the functionality of those modules in alternative embodiments.

It will be understood that whilst the embodiments described herein as including particular components and arrangements of those components, any suitable type and arrangement of components may be used in alternative embodiments. For example, any suitable type of devices, processor, server(s), devices, displays and wired or wireless communication circuitry may be used in alternative embodiments in order to implement the functionality described herein.

Alternative embodiments, or features of such alternative embodiments, can be implemented as a computer program product for use with a computer system, the computer program product being, for example, a series of computer instructions stored on a tangible data recording medium, such as a diskette, CD-ROM, ROM, or fixed disk, or embodied in a computer data signal, the signal being transmitted over a tangible medium or a wireless medium, for example, microwave or infrared. The series of computer instructions can constitute all or part of the functionality described herein, and can also be stored in any memory device, volatile or non-volatile, such as semiconductor, magnetic, optical or other memory device.

It will also be well understood by persons of ordinary skill in the art that whilst the embodiments implement certain functionality by means of software, that functionality could equally be implemented solely in hardware (for example by means of one or more ASICs (application specific integrated circuit)) or indeed by a mix of hardware and software. As such, the scope of the present invention should not be interpreted as being limited only to being implemented in software.

It will be understood that embodiments are described purely by way of example, and modifications of detail can be made within the scope of the invention.

1. TERMINOLOGY AND TECHNICAL PROBLEM ADDRESSED BY INVENTION

As an example of an asset bought and sold by means of an order book in a double auction market facilitated by a limit order book, a futures contract is a standardized agreement between two parties to buy or sell an underlying asset, at a price agreed upon today with the settlement occurring at some future date [60]. They are "promises" to buy or sell, and these "promises" can themselves be traded as new information updates the future price. Such trading is typically conducted in a double auction market operated by a centralized clearing house called Futures Exchange [1], such as the CBOE, the CME Chicago Mercantile Exchange (CME), Eurex Exchange (Eurex) and others. For sake of illustration only but not limiting the scope in any way we use the CME to illustrate the practical relevance of our technical solution. Traders can 'quote' a future by specifying a price and notional volume of assets at which they will buy or sell (a limit order) or initiate a trade by placing a market order for a "promise" of a quantity (purchase or sale) at the best price from the standing quotes. A. Terminology: Order Books and Market Operations

An order book is used by N traders that participate in the market, each trader identified via an index i ε [N]. It also includes a (possibly finite) list of L available prices at which buy and sell orders can be made for the desired volume. A price is always non-zero and each underlying asset of the order usually has a reasonable upper bound for the price. We refer to the price only with index I (for the limit orders) in ascending order (i.e., pi < Pi < PL for I ε [L]). The market evolves in round, where T is the maximum number of rounds.

Figure 1 illustrates the main states of a Market as they could be implemented by any means, including a Centralized Sever Exchange as the CME, a state-of-the-art distributed implementation based on multi-party computation or by using the technical solution proposed by the inventors. For illustrative purpose we use a Centralized Exchange in Figure 1 and we ignore the possibility of making a margin call for a broke trader as its addition would be immediate to anybody familiar in the state of the art (See Section III and Table II for additional definitions). The diagram of Figure 1 describes the possible states in which a Market, for example managed by a centralized exchange can be in. For simplicity we exclude the possibility of performing a margin call to broke traders to add more funds instead of being netted out. Such possibility may be immediate to anyone familiar with the state of the art. A typical evolution of the market includes processing orders (Post/Cancel Order phases), netting out broke traders (Margin Settlement phase), and finally offset all positions (Mark to Market phase). The first important functionality is to made available to all traders an aggregated list of all waiting buy and sell (anonymized) orders: the order book. It includes the volume of contracts being bid or offered at each price point. It is illustrated in Figure 11. Figure 11 shows an order book with limit orders. The dashed line is the average mid-price which is calculated by the CME as the (unweighted) average of all price levels. Tarders' holdings are evaluated against the mid-price. The particular security and financial integrity properties that must be guaranteed by a Centralized or Distributed Exchange are described in Section III and the detailed steps to execute them in Section VI below. B. State-of-the-Art Technology to create a Distributed Exchange with a Distributed, Privacy- preserving and Integrity-preserving Order Book

It is possible to implement the above Exchange transition in Figure 1 in a secure, private way by using secure distributed Multi Party Computation (MPC) [25].

A designer skilled in the state of the art has available secure channels between the traders (which in turn can be obtained using standard cryptographic tools), an anonymous network (such as Tor), and a distributed ledger (such as HyperLedger). These assumptions already appeared in several prior works, most notably [7]- He can also use traditional security services linked to distributed payments. In this respect we leverage on some functionalities for anonymous payments, such as those provided by ZeroCash [7]: zero-knowledge succinct non- interactive arguments of knowledge, a.k.a. zk-SNARKs [8, 10]. For example, for a proof of concept implementation we used zk-SNARKs for the managing the evidence about trader's commitment in zero knowledge, and the SPDZ protocol [25] for the multi-party computation. The above works have been used as purely illustrative examples. Any equivalent functionality will obtain the same security guarantees.

The diagram in Figure 1 may be implemented by using MPC. To do so that for every state in the figure one can use the detailed flow of instructions, expressed in linear form in Figure 12 and Figure 13 in Section VI below by having all traders in the market perform at once the same computations so that no trader leams anything except the overall final result of the computation as it would have been made it possible by running the computation through a centralized Exchange.

C. Technical Benefit Provided by the Invention

We provide a method and an apparatus for a distributed exchange and order book by using a novel specially designed combination of Non-Interactive Zero-Knowledge (NZK) proofs and MPC functionalities so that the burden of computation to execute the functionality in a distributed way a set of agents owing each one or more trader devices is mostly on the trader's device responsible for posting or cancelling an order.

In traditional applications of MPC, such as auctions and e-voting, such benefit would not be material: everybody submits one bid or casts one vote. For a future exchange this is important: for example retail and institutional investors are 71 % of traders in the TSX market, but only make 18% of the orders [44]. Traders responsible for the bulk of the over 300K orders per day were "algorithmic traders" who, in 99% of the cases, only submitted limit orders (i.e., never to be matched in an actual trade).

The proposed technical invention is beneficial to the development of distributed, secure privacy-preserving and integrity-preserving exchange and order book that allows for a fair computation share by those traders who infrequently place bids.

2. DESCRIPTION OF THE EMBODIMENTS

The following reviews the key features of the embodiments and provides a summary of the individual components, their interoperation and the rationale. We consider

• A distributed order book where

o confidential information about a trader's position (margin, posted orders, etc.) is stored privately at a trader's own device

o commitment of the above information is stored publicly which might be on a ledger accessible to all trader's devices or individually by each of the traders

• A network of trader devices possibly represented as

o a network module in a trader device to send a certified piece of data representing a non-interactive proof as explained in the method and o a processing module coupled to the network module in the trader's device, to execute the said method,

o a storage module coupled with the processing module to store the private confidential information about the distributed ledger

o a random generator module to generate cryptographically strong random numbers,

o an encryption and proof generation module that use the random generator module to generate the certified piece of data representing a non-interactive zero-knowledge NZK proof,

o a commitment module that use the random generator module to augment the piece of data so that the resulting generation of the module is a piece of data representing the commitment to trader's private information while being disassociated from the actual content of the piece of data to be used in the non- interactive proof which could be implemented but not limited to by an hash function,

o a verifier module to check the received piece of data corresponding to the non- interactive proof from other trader devices.

o an MPC module that use the random generator module to privately compute a global function's output with other trader devices regarding the trader device's secret input. o wherein the network adapter can broadcast the non interactive proof of a piece of data to the other node possibly by writing to a distributed ledger, for example by adding a ledger module to each trader device,

o wherein the network adapter can also broadcast anonymously an order and the noninteractive proof of a piece of data to the other node possibly by using an anonymous network.

o wherein the processing module has access to a possibly different storage module either directly or indirectly through the network interface to retrieve or store information about the public part of the distributed order book.

• A method to operate such distributed apparatus whereas each state of Figure 1 is specifically implemented by using a suitable combination of NZK and MPC as summarized in Figure 3. Such a method includes a technique to identify a trader's inventory and post/cancel orders via so-called tokens which can be spent/unspent in a publicly verifiable manner, while preserving the anonymity of the trader and the privacy of the trader's inventory, as detailed in Figure 16. It also includes a process, described in Figure 19, based on memoization which allows to fairly distribute the computation in situations where the trading activity might have large variance, by shifting the majority of the burden to the agent owning the trader device responsible for posting/canceling an order. In Figure 3, the functionalities inv, univ, token are not shown as they are always needed to interact with the trader's inventory. The protocols Π^, Ππβ_ΐ, rim** are part of the method and are reported in details in Figure 16. The detailed steps of the method for each node are reported in also in Figure 20. The MPC modules Fcompare. ^{has also} been specifically selected for the invention.

• A method to optimize the above construction so that it scales to a larger number of trader devices to make it suitable for practical futures exchanges. Such a method relies on parallelizing the generation of the NZK proofs output by the proof generator module, by streamlining the validation on the outputs of the commitment module, and by simplifying some of the global functions that need to be computed through the MPC module. The details can be found in Section XII of the attached technical paper.

• A method to extend the mechanism so that trader devices which fail for arbitrary reasons can be penalized. Such a method relies on the random generator module to call the proof generator module and the MPC module, as detailed in Section XI below.

For notational convention we write [v] as the result of Commitment module Com(v; r) for a commitment to value v using random value r ε {0, 1}*. Both v and r are input to the commitment module. Figure 2 illustrate the particular, but not limiting to, embodiment of the network configuration in which a ledger is used as secure broadcast channel and an anonymous network is used for anonymous communication.

Figure 3 maps the overall modules and protocols of the method to operate the apparatus into the overall Exchange State Diagram from Figure 2. They are further detailed in the remainder of the description and in the detailed description of some embodiments of the invention.

3. THE DISTRIBUTED INVENTORY BOOK

The first part of the embodiments is a separation of the information about traders stored into an Inventory Book in three components:

1. The Private Trader Status Book,

2. The Private Inventory Book,

3. For each trader Pi, a Trader Status Crypto Token linking the entries of the two books.

4. The Public Trader Commitment Book and the Public Trader Commitment Book Backup,

A. The Private Trader Status Book

It summarizes the status of each trader device's inventory at each trading iteration t (Figure 4).

Storage: Each trader device Pi is responsible to store its own line of the Table. No other trader device has a knowledge of the values contained in the table.

Initialization: all trader devices are enabled in the Private Trader Status Book, i.e. ffbad]p] = f[del][i] = f[out][i] = 0.

Authorized Operations: "Good" trader devices are allowed to post a limit order in the current round; in contrast, "bad" trader devices (e.g., a trader device netted out during margin settlement) cannot post new limit orders. Such constraint is enforced by the distributed protocol as no other trader has knowledge of these values. The authorized operation will follow the Diagram in Figure 5. Figure 5 shows the required conditions to change flags value: good (0,0,0), broke (1, 0, 0), cancelled (1, 1, 0), and netted (1, 1, 1).

B. The Private Inventory Book

It contains the fields described in Figure 6. Such trader inventory is updated at each trading iteration t. Memorized values are used for the following benefits

1. improve the efficiency of the implementation with respect to the same process as executed by standard multi-party-computation

2. prevent the linking of limit orders during the verification procedure, while allowing the instantaneous computation of rf p].

We call an order a "sell" order if v[i] < 0, otherwise, if vp] > 0, it is a "buy" order. Storage: Each trader device Pi is responsible to store its own line of the Table. No other trader device has a knowledge of the values contained in the table.

Initialization: no contract in the inventory as well as a non-negative deposit for every trader device

Update: Each time a trader device Pi posts an order (I, v), the memoized values are updated as

For order cancellations, or complete matches of pending orders, the reverse computation is performed (Cc = -1).

Multiple Type of Orders: For sake of exposition we illustrate the case where a trader device can either hold long position vp] > 0 or short position vp] < 0 for a single type of order. If multiple type of orders are considered one should replace the single value vp] with a vector of values as obvious.

C. Trader Status Crypto Token

is calculated as the commitment of the concatenation of the fields of the Virtual Traders Inventory Table for the trader device Pi as follows:

D. The Public Trader Commitment Book

It contains a list of cryptographic tokens Tp] for every instant t and trader device Pi. The Public Trader Commitment Book Backup is a backup of the Public Trader Commitment Book to be used to move to mark to market in unfixable state of the market.

Storage: Every trader device Pi can store a copy of the table. Such table might also be stored globally through a distributed ledger.

4. THE DISTRIBUTED ORDER TOOK

A part of the embodiments is a separation of the traditional Order Book into the following components.

1. The Private Order Book,

2. The Public Pending Transaction Book,

3. The Public Trader Commitment Book which is implemented by means of a Merkle Hash Tree, as detailed in Section VIII below, by running the protocols and in

Figure 19.

A. The Private Order Book

The limit order book O for Pi is a sequence of tuples o' whose field are specified as in Figure 7. Storage: Each trader device Pi is responsible to store its own line of the Table i.e. when P'I≡ Pj. No other trader device has a knowledge of the values contained in the table. To avoid that trader devices lie about their past order the other trader devices uses the Public Pending Transaction Book with the given security protocols as they have no knowledge of these private values.

B. The Public Pending Transaction Book

Public Pending Transaction Book replaces the Pi field of the Private Order Book with a cryptographic commitment ΡΊ| and the corresponding information.

5. GENERATION OF THE CRYPTOGRAPHIC COMMITMENTS

The cryptographic commitments generated by the Commitment Module will follow the method described in Figure 8 for every necessary commitment as summarized in Table VIII. Additional commitments are also described in Section VII below.

6. GENERATION OF THE NON-INTERACTIVE ZERO-KNOWLEDGE PROOFS

The method includes the computation of a number of non-interactive zero knowledge proofs by using the module above that have been specifically designed for the application.

The particular NP relations necessary for the proofs used by the invention are summarized in Table I. Some additional values are defined in Table VII. These relations directly test the requirements of Def. 1,2 and 5, whereas other relations are used to validate intermediate results in our protocol construction.

According to the general scheme of Figure 9 a trader device Pi use the proof generation device in the role of a prover and proof generator, while all other trader devices P_j (j≠i) play the role of verifiers.

A proof is a vector of elements which could be, as illustrative but not limiting embodiments, from a bilinear group (e.g. Groth-Sahai) or from a field as a result of the evaluation of polynomial in the field (e.g. SNARKs).

7. INITIALIZATION OF THE PUBLIC BOOKS

For the Public Trader Commitment Book, each trader device i:

1. Use commitment module to generate and broadcast [mp]], τ[ί], np]

2. Use proof generation module to generate and broadcast the proof NIC for mp]≥ 0 with

3. Use proof generation module to generate and broadcast the proof NIC Tp] = where:

4. Use proof generation module to generate and broadcast the proof NIC for ττ[ϊ] similarly.

5. All trader devices use proof verification module to verify all the proofs NZK above

6. All trader devices add Tp] into the Merkle Tree in Public Trader Commitment Book.

7. All trader devices add np] into the Merkle Tree in Public Trader Commitment Book Backup.

The Public Pending Transaction Book is empty.

8. METHODS TO UPDATE THE BOOKS DURING OPERATIONS

The methods to update the Books during the trading operations are described in Figure 3 and are further detailed in Section IX and Figure 20.

1) Update of the Private Trader Status Book: After any update of the Private Order Book

(or Public Pending Transaction Book), the Private Trader Status Book is updated as follows. Each trader device i

1. Use commitment module to generate and broadcast [|m[i]], [|m[ij], |[v[i]|, [v[ij], |[cp]|,

2. Use commitment module to generate Tp].

3. Use proof generation module to generate and broadcast the proof NIC Tp] =

with

4. Use proof generation module to generate and broadcast the proof NIC for Tp] is a leaf of the Merkle Tree in Public Trader Commitment Book.

5. Use commitment module to generate and broadcast

6. Use proof generation module to generate and broadcast the proof NIC for

7. Use commitment module to generate and broadcast

8. Use proof generation module to generate and broadcast the proof NIC for the above commitments are updated correctly as in Fig. 6 with

9. All trader devices use proof verification module to verify all the proofs NZK above

10. Check for new broke trader devices • All trader devices use MPC module with input (f[bad][i], f[bad][i]*) to get the

global output.

• If

returns l, move to next step otherwise skip it.

11. Net out new broke trader devices

• Remove all broke trader devices' pending orders

o Each broke trader device cancels her own pending order as in Section VIII-2 but de-commit to show f[del]p] = 0 instead of f[bad][i] = 0.

o Return to the first step to check for new broke traders and continue to cancel broke trader devices' pending orders until there is no new broke trader devices.

o All trader devices use MPC module Fcompare with input (f[bad]p], f[del][i]) to get the global output,

o If Fcompare returns l, move to next step otherwise skip it.

• Liquidate all broker traders devices inventory

o Each broke trader device post order to offset her own inventory as in Section VIII-2 but de-commit to

o Return to the first step to check for new broke trader devices and continue to cancel broke trader devices' pending orders until there is no new broke trader devices.

o All trader devices use MPC module with input (f[bad][i], f[out]p]) to get

the global output,

o If Fcompare returns l, restart this step otherwise move to next step.

12. Check for unfixable state

• All trader devices use MPC module with input η[ί] to get the global output.

• If Fpcheck returns 1 , move to next step. Otherwise move to Mark To Market with the Public Trader Commitment Book Backup.

13. Use proof generation module to generate and broadcast the proof NIC for Tp]* =

14. Use proof generation module to generate and broadcast the proof NIC for ττ[ϊ]* similarly.

15. All trader devices use proof verification module to verify all the proofs NZK above

16. All trader devices add Tp]* into the Merkle Tree in Public Trader Commitment Book.

17. All trader devices add up]* into the Merkle Tree in Public Trader Commitment Book Backup.

2) Update of the Books when Posting/Canceling an Order A trader device can post/cancel an order by:

1. Use commitment module to generate and broadcast

2. Use commitment module to generate τ[ί].

3. Use proof generation module to generate and broadcast the proof NIC Tp] =

5. De-commit to show that†Tbad][i] = 0.

6. add o = (t, I, i, v) into Private Order Book

7. broadcasts (t, I, v)

8. Use commitment module to generate and broadcast [Pi]

9. in case of posting order Use commitment module to generate and broadcast [|mp]*],

. then Use proof generation module to generate and broadcast the proof

NIC for

with Otherwise do the reverse.

10. Use commitment module to generate and broadcast

11. Use proof generation module to generate and broadcast the proof NIC for

12. Use proof generation module to generate and broadcast the proof NIC for

13. All trader devices use proof verification module to verify all the proofs NZK above

14. All trader devices add (t, I, v, [Pi]) into Public Pending Transaction Book.

15. Use proof generation module to generate and broadcast the proof NIC for

16. All trader devices use proof verification module to verify all the proofs NZK above

17. All trader devices add τ p]* into the Merkle Tree in Public Trader Commitment Book.

3) Update of the Books when Posting/Canceling an Order A match of two opposite orders in the Public Pending Transaction Book, for a buying trader device (resp. selling trader device) at matching price I and volume v: 1. Use commitment module to generate and broadcast [|m[i]|, [|m[ij], |[v[i]|, [v[ij], [cp]],

2. Use commitment module to generate Tp].

3. Use proof generation module to generate and broadcast the proof NIC Tp] =

4. Use proof generation module to generate and broadcast the proof NIC for τ[ί] is a leaf of the Merkle Tree in Public Trader Commitment Book.

5. Use commitment module to generate and broadcast [mp]*]], Ivp]*II

6. Use proof generation module to generate and broadcast the proof NIC for

and additionally in case of a complete match Use commitment module to generate and broadcast

and Use proof generation module to generate and broadcast the proof NIC for c

7. Use proof generation module to generate and broadcast the proof NIC for

with

8. All trader devices use proof verification module to verify all the proofs NZK above

9. All trader devices add τ p]* into the Merkle Tree in Public Trader Commitment Book. 4) Update of the Books when Marking to Market: For each trader

1. Use commitment module to generate and broadcast

2. Use commitment module to generate Tp].

3. Use proof generation module to generate and broadcast the proof NIC Tp] =

5. Use commitment module to generate and broadcast [mp]*]]

6. Use proof generation module to generate and broadcast the proof NIC for

7. Use proof generation module to generate and broadcast the proof NIC for

with

8. additionally de-commit to show that

• f[bad]p]* = f[del]p]* = f[out][i]* = 0

10. All trader devices add τ [i]* into the Merkle Tree in Public Trader Commitment Book.

Following the embodiments described above, some further background relating to futures market exchange is now provided which is then followed by further embodiments.

II. INTRODUCTION

A futures contract is a standardized agreements between two parties to buy or sell an underlying asset, at a price agreed upon today with the settlement occurring at some future date [60]. They are "promises" to buy or sell, and these "promises" can themselves be traded. Such trading is

conducted in a double auction market operated by a centralized clearing house called Futures Exchange [1], such as the Chicago Mercantile Exchange (CME). Traders can 'quote' a future by specifying a price and notional volume of assets at which they will buy or sell (a limit order), or initiate a trade by placing a market order for a "promise" of a quantity (purchase or sale) at the best price from the standing quotes.

General financial intermediation as embodied by a Futures Exchange is still centralized and more expensive than traditional payment networks which have been successfully challenged by Bitcoin[52]. ZeroCash [7] amongst others.

As opposed to simple decentralized price discovery [21], making a full trading exchange distributed requires the designed to solve several security challenges, besides the typical security issues of distributed payments which can be solved by leveraging (and indeed we do so) on ZeroCash [7]: zeroknowledge succinct non-interactive arguments of knowledge, i.e. zk- SNARKs [10].

The first challenge is the interplay between security and economic viability [47]. Whereas integrity is obviously needed for payments (see the Ethereum DAO mishaps [22]), confidentiality seemed less critical for exchanges [21]; one can trace all transactions to a Bitcoin's ID by using public information in the blockchain, yet this hardly stopped Bitcoin from thriving [7, p. 459]. Here, disclosing a trader's account allows attacks based on price discrimination and would inevitably lead to a market collapse (we illustrate this effect in section IV).

Another challenge w.r.t. other crypto applications such as auctions (e.g., [58]) is the simultaneous need to i) make publicly available all offers by all parties, ii) withhold the information on who actually made the quote and iii) trace the honest consequences of an anonymous public action to the responsible actor. The prototypical example is posting a public, anonymous buy order while personally accruing the revenues from the sale (without even the seller knowing the actual buyer and vice-versa). The Exchange must also guarantee that iv) actors do not offer beyond their means, which is an issue related to double spending [4], double voting [12], or groundless reputation rating [67]. E-voting provides traceability for one's own vote, not to the ensemble of agents. Applications of e-cash and privacy-preserving reputation systems guarantee anonymity for honest actions and traceability only in case of malfeasance, not for honest behavior.

In contrast, financial intermediation is not monotonic: Alice's asset (e.g. a trader's inventory) might be proven (cryptographically) valid by Alice and later made (economically) invalid by the honest Bob who, by just offering to sell assets and thus changing the market price, can make Alice bankrupt without any action on her side. Hence, v) security evidence by honest parties must be potentially discarded, and vi) the protocol must account for Alice's "honest losses" and fix them because there is no centralized exchange covering them.

Our contribution. We provide the first, secure, distributed Futures Market Exchange which replicates the functionalities from the CME Globex specifications manual, including each of the main quote types (limit and market orders), needed to build more complex quotes and all standard margin accounting and marking to market features.

Our goals are the following:

1) To put forward a cryptographic ideal functionality for a distributed futures market, that captures all of the key security requirements. This is an ideal realization of a distributed futures market, where the market is run by a trusted third party which knows the secret inputs of all the traders participating in the market, and lets the market evolve on their behalf. Such a functionality, by construction, embodies features (i)- (vi) described above.

2) To design a cryptographic protocol securely realizing our ideal functionality. Our protocol combines multiparty computation (MPC) and non-interactive zero-knowledge proofs on committed inputs, only relying on the basic assumptions of secure broadcast channels between traders and an anonymous network. These assumptions already appeared in several prior works, most notably [7]. We replace the local constraints verification of the MPC with non-interactive proofs for efficient generation of publicly verifiable transactions and scalability w.r.t. the number of traders. Full MPC is only performed for sub-tasks capturing the non-monotonicity and anonymity requirements of the market. We prove the security of our protocol with security-with-abort— where we allow an adversary to abort the computation after receiving its own intermediate outputs [35]— and extend it so that an aborting adversary is penalized by forfeiting its hard won stake in the market, the ultimate discouragement in our setting.

3) To show that our approach is feasible. We do so, by providing a proof of concept implementation using zk-SNARKs for the zero-knowledge proofs, and the SPDZ protocol [25] for securely realizing the required MPC sub-tasks. We further optimize our protocol in order to yield a 70% efficiency gain. Our results show that our solution is feasible for low frequency markets at CME (e.g. trading in Lean Hog commodities): a trading day can be executed in a day by an Amazon's EC2 large VM. Further optimizations are needed for high frequency trading in the largest markets (Eurodollar, Foreign Exchange and Crude Oil futures), for instance by parallelizing proof generation as most of them are independent, improvements in the zk-SNARK implementation; different commitment functions or batch proofs for good standing (e.g. proving the validity of a trader's inventory for a range of prices); or buying a 30M$/year hardware such as the CME data centre.

Non-Goals. A focus of the present invention is to protect against operational attacks on integrity, anonymity and confidentiality, economics and social attacks are, and always will be, possible similarly to centralized systems (e.g. insider trading or cartels manipulating the underlying assets) and they are typically dealt with, ex-post law enforcement [45].

Technical challenges. The main difficulty that we need to face is the fact that futures markets are fully stateful systems where at each round the functionality changes its internal state, due to a valid move performed by an agent which updates the public information and her own private information. As mentioned, the global constraint is such that an agent's legitimate move can unpredictably make another agent's state invalid due to the change in the public information. The market as a whole must transit to a new state where the legitimate move is accepted and the invalid state is fixed. This intrinsic feature (which we feel is best described by non-monotonicity) limits the ability of protocol designers to improve on communication complexity by replacing interactive MPC steps with independent non-interactive proofs.

While the satisfaction of individual constraints could be solved by a standard "commit-and- prove" approach among the concerned individuals, this would not work for the global constraints. The alternative would be to implement the whole functionality via general-purpose MPC. However, this solution is unacceptable given the large variance in trading activity: some traders only make few large orders, others make several trades every milliseconds [44]. This leads to an efficiency requirement (which we dub proportional burden), informally stating that each computation should be mainly a burden for the trader benefiting from it, which cannot be met by a naive MPC implementation. This intuition is confirmed by our experiments, which show that our approach is superior under some general conditions that are realized in practice.

In the rest of the description we introduce the key aspects of futures markets (section III) and illustrate a price discrimination attack due to loss of confidentiality (section IV). A formal model of the centralized futures market (section V) is followed by the description of the ideal functionality its secure distributed version (section VI). Then we describe the (nonmonotonic) security state of the functionality (section VIII), our crypto building blocks (section VII), and our protocol (section IX). We provide a proof sketch on its security (section X) and discuss how to go beyond security-with-abort (section XI). Our proof of concept and its performance results are presented in section XII and section XIII. Finally, we survey related work (section XIV), and conclude the description (section XV).

III. AN INTRODUCTION TO FUTURES MARKETS

To illustrate how markets work, we explain the key trading mechanisms and discuss some aspects of the market microstructure of futures contracts [33], [34]. Fundamental participants in a futures market include traders, exchanges and regulatory bodies as summarized in Table II.

Traders post buy (bid) or sell (ask) orders for a specific futures contract in the market. The trading position characterizes a trader as a buyer or a seller sellers take short positions by selling an amount of futures contracts; buyers take long positions by buying futures. Obviously buyers prefer to purchase contracts at lower prices and sellers prefer to sell contracts at higher prices. Traders can also cancel orders immediately after having posted them to adapt to fast changing markets (a heavily used feature).

The Exchange acts as centralized intermediary between buyers and sellers and guarantees price discovery, matching and clearing. It manages risks and guarantees the fairness of the market (See Table II for a short summary of key requirements from an economic perspective).

The first important functionality is to made available to all traders an aggregated list of all waiting buy and sell (anonymized) orders: the central limited order book. It includes the volume of contracts being bid or offered at each price point. It is illustrated in Figure 11.

Buy and sell orders at the same prices are matched by the Exchange until the required volume of contracts is reached. Matched orders will go through a clearing and settlement process to complete a transaction [56]. The exchange usually operates its own clearing house which is responsible for having a daily settlement for each futures contract by the process of "mark-to- market", which is valuing the assets covered in future contracts at the end of each trading day. Then profit and loss are settled between long positions and short positions.

Table III illustrates the variability of the markets by comparing some days for the Eurodollar, the largest market in the world, together with Lean Hog, a less frequently traded futures.

Informal Properties. From a security perspective an exchange is clearly an instance of a multiparty reactive security functionality [18]: every agent must satisfy individual constraints (monotonic) and the system as a whole must satisfy global constraint (possibly nonmonotonic). The economic requirements in Table II can be directly transformed into the security requirements below.

Availability of Order Book with Confidentiality of Trader Inventory. Acting as counter party for each trader, the exchange must hold all trading information including prices, volumes, margins, and traders ownership of orders, etc. It has to protect a trader's own inventory without leaking it to other traders.

Market Integrity and Loss Avoidance. The exchange implements trading (execute matching orders), and guarantee final settlements (traders' margin meet posted orders) after each event to ensure the integrity of the marketplace. More constraints such as limiting a trader's largest position are added in practice (we omit them due to lack of space).

Trader's Anonymity. The exchange must prevent the linkage of orders by the same trader. This is done by managing an anonymous central limit order book where only bid and ask prices are publicly available. In this way, traders will not be able to identify and forecast others' trading strategies.

Trader's Precedence Traceability. The exchange must allow the linking of limit orders to the individual traders so that matching orders can be accrued to the traders who made them in the exact order in which they were posted.

In traditional applications of MPC, such as auctions and e-voting, there is no difference between the parties: everybody submits one bid or casts one vote. This is not true for general financial intermediation: retail and institutional investors are 71% of traders in the TSX market, but only make 18% of the orders [44]. Traders responsible for the bulk of the over 300K orders per day were "algorithmic traders" who, in 99% of the cases, only submitted limit orders (i.e., never to be matched in an actual trade). Such a difference must be accounted for by any protocol, an efficiency constraint that we state below.

Proportional Burden: Each computation should be mainly a burden for the trader benefiting from it (e.g. posting an order or proving one's solvency). Other traders should join the protocol only to avoid risks (of failed solvency).

IV. LOSS OF ANONYMITY AND PRICE DISCRIMINATION

If confidentiality and anonymity fail, some traders can act strategically by posting orders that they do not intend to honor so that other traders will be maliciously forced out of the market(see the Risk Management entry from Table II in xlll). This attack has been first reported by [47].

Assume Alice, Bob, Carol, and Eve are in a market. Alice accumulates a large short position of 90 contracts selling at $10 each, each other trader buys 30 contracts from Alice at this price. In English, her inventory holds 90 promises to sell. To estimate a trader's exposure, the Exchange assumes that all contracts are bought and sold instantaneously at the current mid price of $10 (See Figure 11). So, to fulfill her promise to sell 90 contracts Alice would have to buy them first from the current mid price and reduce her cash availability to 1400 - 90 x 10 = 500. We have the situation shown in Table IV (left).

If Alice could wait, she could post a buy order of $9.50. If somebody eventually matched her order later in the day she would obtain a modest profit (50c per contract). If Carol and Eve know that Alice is a small investor and needs cash, they can generate an instant profit by changing the liquidity profile of the market. They can post buy orders at slightly higher prices, this changes the mid prices and pushes the liquidation price of Alice's position higher. Alice could try to sell to those buy orders, but this pushes the contracts more deeply negative in a rising market exacerbating her problem of being close to the margin call. Eventually, the liquidation price is high enough, e.g. $16, that Alice's net position is below the margin call threshold and Alice is cashed out, with a realized payout to the other traders, i.e. her $500 is given to the other traders. The other traders can then cancel their orders and the price could then decrease back to $10 or even lower (when Alice's trades would have been profitable), but Alice cannot benefit from this price as she has already been cashed out The other traders have not actually traded anything and still forced Alice to a margin call just by adjusting their buy quotes strategically. Thus, Eve and Carol have price discriminated Alice: their pricing strategy could only work because they knew exactly how much was in Alice's pocket and therefore how much was needed to nudge her out. The opposite problem can be generated from a long position and the market then being artificially deflated.

V. FORMAL FUTURES MARKET DEFINITION

Formally a futures market consists of N traders, each trader identified via an index i ε [N], and a sequence of L available prices (for the limit orders) in ascending order (i.e., Pi < Pi < PL for I ε [L]). In the CME Globex, trading operations starts with an indicative opening price (IOP). Other prices are an integer number of upward or downward ticks from the IOP. A price is always nonzero and each underlying asset of a futures contract usually has a reasonable upper bound for the price. Hence we can map possible prices into a finite list of L available prices and refer to a price only with its index I. The market evolves in rounds, where T is the maximum (constant) number of rounds. At CME an open cry starts at 7:20 and ends at 13:59:00, the evolution of time is accounted for by with the number of rounds. The data stored (and updated) for the current round t e [Γ] is a tuple (O, I). • The set O is the limit order book, and consists of a sequence of tuples

where o' represents a limit order posted at round t'≤ t by a trader Pi for a desired volume

•

To express the constraints that a trader can meet her obligations and make orders within her means we introduce some auxiliary functions. The instant net position η[ί] is the cash she can get (or must pay) upon liquidating all her contracts:

Hp] = mp] + cash(vp]) (1)

where cash(vp]) represents the liquid value of the inventory, i.e., the amount of cash a trader Pi can get (or must pay) upon selling (or buying) all volume holding vp] at the current buy (or sell) quotes in the order book.

The function .^" represents the estimated value of a trader's inventory variables if the market accepted her new order. Auxiliary definitions used in the calculation of market conditions are listed in Table 4 (mid price, best sell price, etc.) while cash(vi) is defined in Table 5. For the estimated value of the inventory when a trader Pi posts an order (t, I, i, v) at price pi for a volume v in round t, we have:

We can now formalize the properties, which must hold at every round, corresponding to the security/economic requirements informally introduced in §lll.

Definition 1 (Market Integrity). The amount of cash available by all traders is constant, i.e.

where mp]' is the margin at time t'≤ t), the total volume holding is zero, i.e.

and the best buy price is less than the best sell price (

Definition 2 (Traders Solvency). All traders have a positive instant net position (qp]≥ 0) and can afford the new limit order at posting time (rfli]≥ 0). Definition 3 (Availability of Orders with Anonymity of Trader). For any order (t, I, i, v) posted at time t, the order information (t, I, v) must be made public before time t + 1 , whilst information about i is only known to Pi.

Definition 4 (Confidentiality of Trader Inventory). Only Pi knows the values of \\ = (mp], v[i]) as well as rjp] with the exception of time T after mark-to-market when v[i] = 0.

The two previous requirements imply that m[i] and v[i], as well as rfli] must also be confidential (otherwise one could recover the inventory by reversing the computation from orders).

Definition 5 (Trader's Precedence Traceability). Let O be the current order book, (t, I, i, v) be an order, and t' be the smallest round t' < t such that (f, I, i', -v") 6 O then the order book O* at time t + 1 respects traders precedence given order (t, I, i, v) and order book O iff

)}

VI. THE IDEAL REACTIVE FUNCTIONALITY

For expository purposes, both in the functionality's and in the protocol's description we allow an adversary to abort the computation after receiving its own intermediate outputs. This flavor of security is known as security with aborts [35]. In Section XI we change the protocol to avoid scot-free aborts.

The futures market evolution is captured by an ideal reactive functionality F_CFM where all the traders send their private initial inventory to a trusted third party (during the so-called Initialize phase), which lets the market evolve on their behalf. A typical evolution of the market includes processing orders (Post/Cancel Order phases), netting out traders with insufficient funds to maintain their position, we refer to these traders hereon as "broke" traders (Margin Settlement phase), and finally offset all positions (Mark to Market phase). A formal description is in Fig. 12.

Intuitively, the matching process performed during the Post Order phase (c.f. Fig. 12). Takes the new order (t, I, i, v) and tries to match it with all previous limit orders of opposite side in the order book that have the same price. In other words, if the limit order is a buy order it will be matched with a sell order, and vice versa. The priority to match is given to the limit order with a smaller round index. When a match is found, the trade is reconciled, and the available cash, as well as the volume holding of the traders, is updated accordingly (i.e., on buy side: increase volume, decrease cash; on sell side: decrease volume, increase cash). The matching process stops either when the new order is fulfilled, or there is no past order that can fill the new one. In the latter case, the remaining volume is left in the order book as a new limit order.

An important feature of FCFM. is to guarantee payable losses by each trader (i.e., ηβ]≥ 0). Hence, when the last round is reached, all traders must then offset their position, so that the data at round T will consist of all zero volumes, non-negative balances, and an empty order book. Since the net position might change (due to the updates of the order book) it is necessary to check the new instant net position ηβ]* of each trader Pi after the update. In case of any negative net position, the last update cannot be committed until all broke traders Pi (i.e., Hp] < 0) are netted out, which is done in the so-called Margin Settlement phase, (c.f. Fig. 13). This requires each new broke trader to cancel all pending orders (becomes canceled), and buy/sell all contracts in the inventory that the trader is short/long, at whatever price available at the moment (becomes netted). At the end of the Margin Settlement phase the order fulfillment is resumed, and the update will be committed.

For simplicity, after a trader Pi is netted out, the trader cannot participate in the market in the subsequent rounds. 5 In the worst-case scenario where: (i) the market cannot supply the margin settlement of broke traders (because, e.g., they hold too many contracts comparing to the current available volume in the order book), or (ii) even the margin settlement cannot bring a broke trader's position back to non-negative, the ideal functionality proceeds directly to Mark to Market.

Non-monotonicity. A challenging feature of the futures market's ideal functionality is its intrinsic non-monotonic behaviour, in a sense made precise below.

Remark 1. The properties of private values belonging to a honest trader Pi executing the ideal functionality of Fig. 12-13 are non-monotonic in the actions of other honest traders: Let Pi be a good trader (private value η[ί] > 0) at round t with order book O, and further assume that at round t+1 the order book gets updated to O* due to an offer posted by another good trader P_j≠ Pi. The new order book O* affects the value cash(vp]) (Table VI), which might result in a negative instant net position ηβ] (Eq. (2)), thus making Pi a bad trader at round t+1 , even if it was inactive during that round.

Security properties. We briefly illustrate why FCFM fulfils the security requirements of the futures market in section III. The Availability of Orders with Anonymity of Trader property is guaranteed by broadcasting only (post order, I, v) upon receiving a (post order, Pi, I, v) from Pi. The same reasoning applies for canceling orders. Confidentiality of Trader Inventory is guaranteed as FCFM keeps the trader's inventory secret, all broadcasts post order, cancel order, invalid post, invalid cancel, match and remove contains no inventory information (mp], v[i], η[ί], m[i] or v[i]). As all the computations of F_CFM respect the conditions in Def. 1 and Def. 2, Market Integrity and Traders Solvency properties are preserved. The Trader's Precedence Traceability property is also maintained due to: (i) only the owner of an order can match/cancel that order and (ii) only a good trader can post/cancel in normal phase while only broke traders can cancel and canceled traders can post during margin settlement phase. The Proportional Burden is obviously satisfied because we have a centralized functionality. We return to its satisfaction on the actual distributed protocol.

VII. ASSUMPTIONS AND CRYPTO BUILDING BLOCKS

We elected as much standard crypto blocks as possible for both protocol construction and reliability of security proofs.

Anonymous Communication Network and Secure Broadcast Channel Recall that the futures market ideal functionality guarantees full anonymity of the traders. To this end, we assume an underlying anonymous network that hides the traders' identifying information (e.g., their IP address). This assumption was already used in several prior works, most notably [7]. We also assume secure broadcast channels between the traders. Such channels could be implemented by utilizing a consensus protocol, e.g. PBFT [19].

Initial Bootstrap: As we employ several zero knowledge functionalities in our protocol, instantiated with zk-SNARK [10], an initial setup is required for global information such as proving keys and verifying keys, which can be achieved securely in practice with MPC as in [9]·

Commitment Schemes. We rely on a non-interactive commitment scheme Com, with domain {0, 1}*. We typically write [v]] := Com(v; r[v]) for a commitment to value v using randomness rfv] E {0, 1}*. To open a given commitment fly]], it suffices to reveal (v, r[v]), so that a verifier can check that [v]] = Com(v; rfv]). For the proof of security we need that [v]] statistically hides the committed value v, and after publishing [v]] it is computationally infeasible to open the commitment in two different ways. We follow [30] for the formal definitions. We use the following standard NP relations: (i) R", for validity of commitments;

for ownership of an opening; for commitments to non-positive (resp.

non-negative, negative) values; (iv) R⁶⁰, for equality of two openings; for commitments

to values different from a pre-defined constant.

Hybrid Ideal Functionalities. To implement FCFM we use hybrid ideal functionalities, with the usual simulation-based proofs relying on the composition theorem [17]. All our functionalities receive some values/randomnesses and the corresponding commitments, and must first check whether the commitment actually corresponds to the claimed value, returning l otherwise (as in R"). The remaining features outlined below are specific to our application. They are similar to range proofs [14, 16].

• The Secure All Positive Check functionality Fpctwck receives from every trader the net position η[ί] and guarantees solvency

• The Secure Sum Comparison functionality Fcompare receives from every party a pair of old and new binary flags {f[i], f[i]*}. It checks whether the total number of flags has not changed

• Finally, the zero-knowledge functionality is parameterized by an NP relation R and

receive inputs from a trader Pi in the role of a prover, while all other traders play

the role of verifiers. As usual the prover sends the statement X| and the corresponding witness Wj to the functionality, while each verifier sends its own statement Xj to be checked. Each verifier gets the outcome of

otherwise it gets l. For simplicity we omit the zk subscript. MPC will be identified by subscripts and zk by superscripts.

The NP relations we use are summarized in Table 8. To describe them, we use some auxiliary values that are not needed in the ideal functionality FCFM (albeit they might well be present in an actual centralized exchange implementation). These additional values are defined in section VIII and Table VII. Some of our relations directly test the requirements of Def. 1 ,2 and 5, whereas other relations are used to validate intermediate results in our protocol construction, and share similarities with the NP statement POUR in [7].

VIII. SOLUTION OVERVIEW

The first challenging part of the protocol construction is to identify a suitable form for the state of the reactive security functionality implementing FCFM that would account for its non- monotonic behavior in the legitimacy of traders and assets. A simple (but wrong) solution would be to use just the private inventory values of the individual traders. Each trader could prove in ZK that it respect the constraints stated in Def. 1 , 2 and 5. Unfortunately, the arrival of new valid orders could make the constraints of some other trader invalid, i.e. the protocol should no longer consider her ZK proof valid.

We must also store such a state in a way that after an order is accepted by the market (i.e. the ensemble of agents) it is not possible to link it to the next order by the same trader. This cannot just be the union of the individual (unopened) inventories. By looking at the unchanged inventories the traders could identify the trader who did the order. A global MPC step to update the entire state would be a solution but it would put an unnecessary burden on the other traders. A further challenge is that we must keep a fully ordered list (Matching orders must be executed according to arrival time).

First, we augment the private state of each trader with additional information besides the inventory mp] and vp]. We memoize the value of the estimation m[i] and vp], and a counter cp] to track the number of pending orders. Each time a trader Pi posts an order (I, v), the memorized values are updated as mp] = mp] - pr v, v[i] = vp] + v, and c[i] = cp] + 5_C where 5_C = 1. For order cancellations, or complete matches of pending orders, the reverse computation is performed (5_C = -1). The use of memoized values is a quick calculation to do and to verify cryptographically. Yet, the foremost reason for such device is that the values mp], vp] of a trader are needed to prevent the linking of limit orders during the verification procedure, while allowing the instantaneous computation of rf[i].

Memorization avoids the use of MPC when addressing the conflicting requirements of i) providing a public trail of events, ii) publicly verifying a constraint on a private subset of such events as well as iii) showing that such private events are all and only applicable events. To meet (iii) Alice would have had to show which orders belonged to her to add them to her estimated net position. Since the full order book is visible (i), her full trading strategy would then be visible to the other players. In contrast, if we make sure that an order is private to trader Bob (ii), this very property does not allow Alice to prove that the order in question does not belong to her (and does not make her over budget), so failing (iii). A full MPC protocol would be a solution but this would force other traders to participate to the posting of any order from a third party. As mentioned, such burden would be considered unacceptable. Next we introduce three flags to represent the status as a potentially broke trader. A trader's inventory is marked with a state represented by the three flags f[bad]p], f[del]p], f[out]p]. We call an inventory with a non-negative instant net position a good inventory (f[bad][i]=0, f[del][i]=0, f[out][i]=0), otherwise it is a broke inventory (f[bad][i]=1 , f[del]p]=0, f[out][i]=0). A good trader can do a normal post/cancel action, while a broke trader has to cancel a previous order in the Margin Settlement phase. Finally, we call an inventory canceled if it is a broke inventory with no pending order (after canceling all orders in the Margin Settlement phase) at the time of commitment (f[bad][i]=1 , f[del]p]=1, f[out][i]=0); an inventory is, instead, netted if it has a zero volume holding (after matching to an offset position during Margin Settlement) at the time of commitment (f[bad]p]=1 , f[del]p]=1, f[out]p]=1). The state transition diagram in Fig. 14 shows how the inventory switches from one state to another, as well as the condition causing the transition. This status will be key to capture the non-monotonic evolution of the validity of commitments and zk proofs once a valid order (of another trader) is accepted.

The overall state is then captured by a token Tp] that is a commitment of all values in the inventory (with fresh randomness rp]); initially, such value is only known to the trader itself. Each trader keeps the token secret and broadcasts a commitment to it in order to commit to a new inventory; such an inventory is considered as unspent. At a later point, a trader can reveal the token and retrieve a previously committed inventory, in which case we say the inventory is spent, as the corresponding token cannot be used anymore.

The anonymity of the inventory is guaranteed by relying on Merkle trees [48] in conjunction with the zero-knowledge proofs (as in [59]). Throughout the execution of the protocol, a Merkle tree T based on a collision-resistant hash function H : {0, 1}*→ {0, 1}* , where the leafs are commitments, is maintained and updated, p denotes the root of the tree, and path denotes the authentication path from a leaf [v]] to the root p. As in [59, 7], the number of leafs is not fixed a-priori, one can efficiently update a Merkle tree T by appending a new leaf, resulting in a new Merkle tree T with root p; this can be done in time and space proportional to just the tree depth. Table IX summarizes the supported operations Add, Path and Auth of a Merkle tree T .

Preserving Traders' Anonymity. The commitment (the retrieval) of trader inventories to the Merkle Tree T is obtained by running a sub-protocols flpu, (resp. fig*) as follows: • Executing protocol Πρ,*, the trader broadcasts a commitment to the token corresponding to the current inventory: τ[ϊ] = Com(m[i]||v[i]||m[i]||v[i]||c[i]||f[bad]p]||fIdel]p]||f[out]p]; r[i]) Thus, the trader proves that the token is correctly constructed (using F^,oken) and appended into the Merkle tree T (with operation Add), before broadcasting the new root of the tree. The other traders will check that the new root is correctly computed before accepting it.

• In an execution of protocol llget, a trader can retrieve a previously committed inventory (say, at round t' < t), and spend it for posting or canceling an order (I, v), by revealing the secret unspent token τ[ί]' and proving that the newly committed values are consistent updates of the values committed at round t'; this is done using F"™ (to retrieve the inventory) and then

(to update the inventory); in particular, [τ[ί]']] is a leaf of the current tree and

cp]' +5_C, while all the flags f[bad]p], f[del]p], f[out][i] stay the same. Every time an inventory is retrieved, two sets of commitments are generated corresponding to the inventory values before and after the update. The token τ[ί]' is now marked as spent and will not be usable for retrieving any inventory.

The main Merkle tree T can also be forked (via sub-protocol see below) into a backup

tree TU to use during the Mark to Market phase in case there are still traders with a negative net position even after the Margin Settlement phase. We use this feature to challenge the non- monotonicity of security and go beyond security-with-abort.

IX. PROTOCOL CONSTRUCTION

At this point an easy solution would be to just run the entire reactive functionality as a global MPC. As we mentioned, this would be unacceptable from the perspective of most traders: the burden of computation should be shifted to parties wishing to prove something (e.g. their good and bad standing). As such, only when global consistency of the market is at stake should all traders be involved. We illustrate this empirically in §XIII. Fig. 15 summarizes how the various security functionalities and sub-protocols have been used to implement each step of the global ideal functionality. Our stateful functionality traverses several states. For every state of we show which NI-ZK proof steps are required, as well as the MPC steps. The subprotocols llget, riput and their functionalities inv, univ, token are always needed to interact with the trader's inventory.

First we present a few useful sub-protocols that are extensively used during different phases of our main protocol.

Common Sub-Protocols

The protocols in Fig. 16 below are used extensively as sub-routines in our main protocol.

We denote by the superscript * the updated values, computed locally by Pi after an update of the order book, e.g. mp]*, which are used as common inputs for the sub-protocols. We use it in particular on the commitments of the inventory values, e.g. [m[ij], the related order information

and the Merkle Tree T , where Pi additionally holds the committed values and the corresponding randomnesses.

Every time a trader P posts or cancels an order, say the protocol has to check

for its validity.

Every time the order book is updated via (i) a post/cancel action of a trader Pi, or (ii) a match of two traders P and P_r , all the traders (including P and P_r ), need to be checked for negative instant net position,

for matching an order between Pi and P_r .

fork a backup tree TU* from the main tree T* to serve as a starting point during the

Mark to Market phase in the case there are still traders with a negative net position even after Margin Settlement. The protocol runs with the commitments of the inventory values, as well as the new net position of all traders, as the common inputs.

Protocol Description

The overall protocol runs in 4 phases, which we describe on a high-level below. Formal description can be found in §A of the appendix.

Initialization Every trader participating in the futures market has to commit to a valid initial inventory. This is done during the first round, by each trader individually, as follows.

• P holds an initial non-negative secret amount of cash

zero volume holding (i.e., v[i] = 0), an initial estimation of the cost to pay for pending orders

and an zero estimation of the volume holding for pending orders

as well as all initial zero inventory flags.

• Pj commits to its initial inventory and proves in zero knowledge that such an inventory is valid (as defined above), using the functionalities

for mp] and for mp]; while

simply decommitting vp], v[i], cp] and the flags is sufficient to prove that they are all zeros.

• The traders run protoco

to commit the inventory of Pi; the backup tree TU is initially identical to T.

Post/Cancel Order A good trader can post a new order or cancel a previous order

Margin Settlement This phase is (re) started every time there is at least one new trader with a bad standing (i.e., f[bad][i] = 0 and η[ί]* < 0). It proceeds as described below; afterwards the protocol goes back to the previous phase (whatever it was).

• For each pending order (t\ I', i, v" ) of a broke trader

o The traders run llge_t with parameters (-1, I, v), to retrieve Pi's two inventories: one before the cancellation of the pending order and one after that, o The traders run

o All traders forward the necessary flags f[del]p]* and f[bad]p] to Fcompare to check whether

If the check is successful, move to next step.

o The traders run n,* to check and restart this phase if there are new broke traders.

• The broke traders offset their positions until all broke traders are netted out.

o The traders run llge_t to retrieve their inventory.

o The traders find matches on the order book at the current best price, say between Pi and P_r ; both traders locally update their inventory, commit to the new inventory, and prove in zero knowledge that the matching was done correctly (using

o All traders forward the necessary flags f[out]p]* and f[bad][i] to Fcompare to check whether

if the check is successful, go to next step.

• The traders run Ππ* to check and restart this phase if there is a new broke trader.

• All traders to check if a backup tree can be forked, if not, go to Mark to Market

phase.

Mark to Market This phase is invoked at the last round t = T, or during Margin Settlement.

• The traders to retrieve their inventory.

• The traders locally update their inventory, commit to the new inventory, and prove in zero knowledge that the matching was done correctly

• Finally the new inventory is added back to the Merkle tree T by running

The Proportional Burden is fulfilled for what is technically possible as we require traders posting/canceling an order to prove the validity of their actions before other traders prove the validity of their inventories according to the new order book. The latter is necessary for distributed risk management. It could be optimized by having a trader proving the validity of an inventory for a range of price values rather than just the current price (e.g. up/downward ticks as appropriate).

X. SECURITY ANALYSIS (SKETCH)

The theorem below states the security of protocol IIDFM·

Theorem 1 . Let Com be a statistically hiding (and computationally binding) commitment scheme. Protocol IIDFM securely realizes the ideal functionality

in the

hybrid model, where the zero-knowledge functionality F_zk supports all NP relations defined in §VII. We assume the set I is fixed before the protocol execution starts.

We sketch here the key step of the security proof (See Appendix B for details). As in standard simulation-based security proofs, we exhibit an efficient simulator interacting with the ideal functionality F_CFM that is able to fake the view of any efficient adversaries corrupting a subset I c [N] of the traders in an execution of protocol n_DFM- Our protocol is designed in a“hybrid world” with several auxiliary ideal functionalities (mainly for zero-knowledge proofs and for running secure comparisons). Importantly, in such a world, there is no security issue when using these functionalities: the composition theorem ensures that our protocol is still secure when we replace the auxiliary ideal functionalities with sub-protocols securely realizing them. An advantage of working in the hybrid model is that the simulator gets to see the inputs that corrupted traders forward to the auxiliary ideal functionalities in the clear.

On a very high level, our simulator S works as follows. During the Initialize phase, it commits to zero values for each commitment forwarded by a honest trader in the real protocol; the commitments to the token of each inventory are added to a simulated Merkle Tree that is maintained internally by the simulator. During a Post/Cancel Order action, it relies on the ideal functionality F_CFM to post/cancel the corresponding orders; afterwards, in the Margin Settlement phase, for each match notification received from the ideal functionality F_CFM, the simulator commits to zero for each commitment forwarded by a honest trader in the real protocol execution. During the Mark to Market phase, it commits to zero values for each commitment forwarded by a honest trader in the real protocol. The hiding property of the commitment scheme implies that the above simulation is indistinguishable to the view generated in a mental experiment where the simulator S is given the real inputs corresponding to each honest trader. The only difference between this mental experiment and a real protocol execution is that in the former experiment the market evolves using the inventories held at the beginning by each corrupted trader, whereas in the latter experiment the adversary can try to cheat and fake the inventory of a corrupted trader (e.g., by claiming an order pertaining to a honest trader). However, the binding property of the commitment scheme and the collision resistance of the Merkle Tree, ensure that such cheating attempts only succeed with a negligible probability.

This allows us to conclude that the view simulated in the ideal world (with the functionality F_CFM) is computationally indistinguishable from the view in a real execution of the protocol, thus establishing the security of II_DFM.

XI. BEYOND SECURrTY-WITH-ABORT

If every single party participates to the computation, the baseline protocol is secure. However, an adversary can refuse to join Fcnpare or Fpctwck. or to match an order in Ππ»**, or refuse to cancel pending orders and liquidate her own inventory during the Margin Settlement phase. Therefore, if even a single party is byzantine and aborts, the base protocol cannot continue operating, leading to a clear scalability issue.

A preliminary observation is that in practice one cannot initialize a market with a self-claimed account. The cash that get deposited into the market must be backed by a verifiable source where a debit is acknowledged by every market participants, for instance ZeroCash. Hence, such source must be able to publicly verify the validity of the transactions resulting from the market's operation at the end of the day to credit each the account with the corresponding amount.

An approach is to penalize a faulty participant upon aborting in an MPC, hence make the adversary lose some digital cash in proportion to their actions. For instance, [39] and [40] require the adversary to make deposits and forfeit them upon dropping out. Unfortunately those protocols are not usable in our scenario. Technically the parties have to move in a fixed order since order of revelation is important (the see-saw mechanism, [39, p. 7]) for the aforementioned penalty mechanism to work. This fixed order conflicts with our protocol's anonymity requirement since this will reveal the identity of the trader who made a posting. Most importantly, those protocols are not economically viable as the baseline deposit would need to be the same for each party (and progressively staggered in a see-saw fashion) which is unachievable due to the anticipated heterogeniety in financial capability of traders. In a low- frequency market the trader going first would have to deposit assets 35x times the stake of the trader going last, and in large markets that increases to 500 times larger (See Table III, where a single Eurodollar contract has a notional value of 1 million dollars and margins are measured in basis points). Hence we opt towards the mechanism of Hawk [37, Appendix G, section B] in which private deposits are frozen and the identified aborting parties cannot claim the deposits back in the withdraw phase.

This fits precisely with our scenario as the deposit can be made to match the initial margin (which is the largest amount a trader can lose when being netted out). In practice, traders can deposit additional funds when receiving a margin call. These incremental deposits could be easily incorporated into our setting by querying the deposit ledger for all deposited funds before time t < T as opposed to checking the single deposited value at time 0. At first we must show that honest participants can eventually move by themselves to a Mark To Market phase at least to cash their own inventory. Let us denote by Adv the set of adversaries who abort between time t and time t + 1 given a backup tree TU with a solvable inventory of all traders (m[i], vp]) and the corresponding mid price p. Since TU is a valid tree, it satisfies the constraints from Def. 1 & 2, and therefore η[ί]≥ 0. Since η[ί] = m[i] + cash(v[i])≤ m[i] + p - v[i], we have

This implies that there will be no unexpected loss to cover (0≤ . . .) nor additional money would be created Then honest traders can proceed to the Mark To Market

phase to split their own trade proceedings. If enough traders accept the move so that it ends into the public ledger this would be considered an acceptable solution. From an economics perspective, the adversary would be penalized with at least its initial cash margin which could be substantial.

Now we just need to extend our protocol to identify the aborting parties in various protocol steps and prevent them from claiming the deposit in Mark To Market phase by requiring each trader to present a proof of participation in the round where the abort happens. A further step can possibly be taken to divide the money of the adversary if at the end of the Initialize phase the total sum of money is computed (by an MPC protocol, i.e. Fsum that receives mp] from each trader and computes∑im[i]. In the Mark To Market phase, by computing the sum of money of the honest traders after the updates of the inventories we can find the difference corresponding to the money of the adversary and shares it by updating the inventories again adding the shares.

Formally, in an abort, every honest traders maintain a set of spent tokens τ[ί]' of the participants. The Mark To Market phase now runs exactly the same as before except that a trader must prove in zk s/he knows the opening to a token τ[ί]' that was present in the last step with the relation R⁰"™ which takes as input the statement

and witness

(rpl'.mp], vp], mp], vp], cp], f[bad]p], f[del]p], f[out]p]). The output of is defined to be one if

and only

In the simplest settings, as in a joint step, the set of tokens from participants can be easily constructed. We discuss the disqualification of an adversary in a more complex case, where s/he refuses to match an order o':

• All traders Pi cancel all orders o with o≠ o'.

• All traders Pi prove they do not own o' by decommitting

and showing that cp] = 0. Similarly, if the Margin Settlement phase is aborted,

• In cancellation phase, all traders retrieve their inventory with a token Tp]', and prove that the inventory flags is not broke, i.e. (f[bad][i], f[del]p], f[out][i])≠ (1 , 0, 0).

• In liquidation phase, all traders retrieve their inventory with a token Tp]', and prove that the inventory flags is not canceled, i.e (f[bad][i], f[del][i], f[out]p])≠ (1 , 1, 0).

XII. IMPLEMENTATION

All phases of our protocol have been implemented and optimized. For the anonymous network and the distributed consensus protocol, off-the-shelf implementations will do. We use a distributed ledger, e.g. HyperLedger in PBFT mode (httpr//www.hyper1edger.org) as a byzantine fault tolerant storage for each protocol step, i.e. each broadcast is replaced with a write into the distributed ledger. To communicate anonymously, the traders hide behind a Tor network. While we mentioned Tor, zcash and HyperLedger in our implementation, we replace any sub-protocol with other protocols for the same task, without affecting security. See [2], [63] for a comparison between different solutions. Implementation of Components.

We use a digital cash network that supports a private payment scheme, e.g. zcash for bootstrapping the market's initial cash. We extend zcash's POUR transaction to accept one more input/output: the commitment |[m[i]|, to deposit and withdraw the market's digital cash from and back to the zcash network.

We follow [7] in the instantiation of our building blocks, at a security level of 128 bits. Let H(-) be a collision-resistant compression hash function that maps I bits input (I≥ 512) into 256 bits output (e.g. SHA256). We use H(-) to instantiate the commitment scheme Com and also the hash function for the binary Merkle Tree T . The zero-knowledge functionality FR is instantiated with zk-SNARKs for arithmetic circuit satisfiability [10], while generic MPC is used for the hybrid ideal functionalities Fcompare and Fpctwc*. While SNARKs are problematic in the setting of universal composability [35], they are still sufficient for sequential composition. Our zk implementation is based on the libsnark library. We split F"" into F^imni to first check whether the token is one of the leaf of the Merkle Tree, and then F^hvt to check the consistency of the new commitments and the old token14. Our MPC implementation exploits the SPDZ library, along the construction in [11 , 25, 53]. While libsnark is efficient and scable, SPDZ hits the limit of 10 parties due to the complexity in implementing SHA256 with the library, i.e. right-shift is not natively supported for 320-bits word, and we have to implement it using left-shift and other bitwise operations.

Optimization

We also experimented with an optimized version to reduce the cost to only 30% and overcome the limit of 10 traders for the MPC. To improve the performance of the protocol we first streamline the number of the validations of 5 the commitments by packing f[bad]p], f[del][i], f[out][i] into a single integer fi, this improves the circuit as well as Then we can

combine the circuits

and

Proof generations can also be parallelized in a protocol step, e.g. in and are independent of each other.

Further, functionalities and are used extensively throughout our protocol. As we

shall see in Table 11 , the consistency check of the commitments slow down the whole protocol. We can replace

with a lighter functionality F^c below to detect the flag in an unwanted state (without validating the consistency of the commitments) and randomly select a P_y owning an unwanted state to open the flag to check. This is not a problem as P_y cannot be traced to any traders from the previous steps or the subsequent ones due to the anonymity mechanism (Merkle Tree and ZK Functionalities). She is just an anonymous volunteer for this round. The functionality Fpctwck can be similarly replaced.

The Secure Detection Fee runs on common input (f) and interacts with a set of players (Pi, . . . , P_N) and receive (Pi, ffj], rfj]) from each Pi. Upon receiving all inputs, let cf be the number of pairs (ffj] = f), if cf > 0 output y =∑ r[i] mod cf to all players and l otherwise.

In the protocol, first each trader samples a random rfj] and forwards Pi, ffj], rfj] to F_mc with common input f to obtain y or l. In case of l, each trader Pi proves that her flag is different from the f (using Fnec)- Otherwise trader P_y proves that the inventory flag is the same as the common input (by decommitting the flags). Any trader not able to prove this is considered as aborting.

XIII. EVALUATION

We evaluate our protocol in 3 steps. First we evaluate the performance of the cryptographic primitives that we use in our protocol, i.e. the zk-SNARK circuits and the MPC functionalities, both in the offline and online phase on a concrete implementation. Then, we use the obtained values to estimate the performance of each phase of our protocol. Finally, we evaluate the full protocol's performance by matching the above estimates with the public data available from the order books. Whilst network latencies are critical for high speed trading, we ignore them here since this issue is well understood by traders by either using known optimizations [51 ,41] or by even buying private fiber-optic lines to cut delays between exchanges.

All our experiments are run with an Amazon EC2 r4.4xlarge instance (Intel Xeon E5-2686 v4@ 2.3Ghz, 16 cores, 122 GB RAM) so we exclude the communication cost (However, each operation requires less than 20 commitments and 10 zk-SNARKs proof, thus per operation the data is less than 4KB. See Table 10.). The MPC protocol's off-line phase can also be pipelined with zk-SNARKs proof generation thus we exclude it as well. zk-SNARK Circuits Performance In Table 10, we report the performance metrics for the preprocessing steps: the key generation time (Key Gen), the size of the proving keys (PK), and the size of the verifying (VK) keys. We also report the time to generate a proof (Proving Time) and to verify it (Verify time), as well as the size of the proof during the actual trading execution described above. As shown, proving key size and proof generation time scale linearly with the number of commitments part of the relation.

Performance of the MPC functionalities To gauge the effectiveness of our MPC components, we evaluate the performance for each functionality separately. Table 11 reports the size of the bytecode and the corresponding running times for 3, 5 and 10 traders. The memory requirement for the compilation of the MPC functionalities using SHA-1 commitments crashed after 10 traders by exceeding 120 GB. We found that the dynamic memory requirement is typically 100x the final bytecode size. This was not reported before (e.g. [25]), and it is an important insight on the limit of the technology.

Overall Evaluation In our experiment, we employ the futures trades in the first quarter 2017 for the Lean Hog futures market (See Table III) from the mentioned Thomson Reuters Tick History database (https://tickhistory.thomsonreuters.com.). For each day, we have five level limit orders (buy and sell, which we also chose for the F"*) and transaction data at ticks level with millisecond timestamps. At a low end, we must be able to support a minimum of 10 traders and this is the limit we chose for illustrating our prototype. From the dataset we cannot determine the status of each trader (trader anonymity!), so we assume they have a large margin and never enter a broke state (i.e. we exclude Margin Settlement). We can combine the number of post, cancel and matched orders from market data (e.g. Table III and XII) to estimate the corresponding execution overhead throughout a day of trading. The final results are reported in Table XII. The actual timing of the protocol is still slow compared to the millisecond delay required by the CME but, if we compare the cost of our hardware (a $500 EC2 instance) to the "centralized competitors" (CME's cost for IT infrastructure is $30 millions per year), we believe that a 103 delay (seconds vs milliseconds) with a 107 cheaper kit is acceptable.

Fig. 17 shows the overall record for the plain and optimized version as well as an estimation of a naive MPC implementation of the ideal functionality. For most of the entire quarter our distributed protocol can be optimized to have no overhead and executes all trades in the very same day. Fig. 17 relates to performance in terms of execution overhead to the expected processing time (1 day). For the optimized version, only one day of trading exhibits overhead greater than 10x and only ten days greater than 5x. These overheads could be already offset by parallelizing the traders ZK-proofs (each trader has to do several of them) which would yield an improvement factor of 6x. To estimate the cost of a naive MPC implementation, we use as building block the simplest of our stateless MPC functionalities F_ec which is used to detect negative inputs and open one index. It costs only 0.2s for 10 traders. We then estimate the cost of a naive MPC implementation of our stateful ideal functionality by accumulating the steps in Fig. 12 and Fig. 15 under the favorable assumption (for MPC) that execution times accrue linearly with the number of steps.

Pure MPC impose a significant burden on retail traders (the overwhelming majority of the market) in particular during peak times when algorithmic traders frequently post and almost immediately cancel practically all orders (See [44]). Our hybrid approach shift the burden on computation on algorithmic traders. As seen from Figure 18, retail traders would devote significant computational resources in a pure MPC implementation for allowing speculators to indeed speculate. With MPC retail traders have to always participate whether they make an order or not (and they overwhelmingly don't [44]). They would be supplying to algorithmic traders some orders of magnitude of costly computing resources. With our approach the burden on retail traders is significantly smaller. The optimized implementation can already break the barrier of ten traders and do the full 66 traders of the peak day. Parallelization can further reduce the runtime of the sub-protocol to just 8s (comparing to 24s of sequential proof generation). Furthermore, additional practical design decisions can further increase the protocol throughput, e.g. if traders can prove that their inventory is valid for a range of prices they would only need prove validity again when the price fluctuates out of that range, or by allowing multiple traders to post/cancel in one round, etc. We leave this for future investigation.

XIV. RELATED WORK

Distributed Ledgers are ledgers maintained by a network of nodes. The most important property, e.g. for distributed payment networks, is consensus among the nodes, while still being fully decentralized. The most prominent example of a distributed payment network is Bitcoin [52], whose core components are the Proofs-of-Work and the Blockchain. The current bottleneck of Bitcoin is its low throughput in terms of transactions-per-second (TPS). (Roughly, 10 TPS compared to 2000 TPS achieved, e.g. by Visa.) Several variants/extensions of Bitcoin appeared recently, including ZeroCoin [50], ZeroCash [7], and Ethereum [26].

Secure Multiparty Computation Seminal feasibility results in the theory of MPC established that any functionality is securely realizable via a distributed protocol in the computational (resp. information-theoretic) setting, assuming honest minority (resp. majority) [66], [31], [6], [20], [57]. The recent progress on efficient implementations of general-purpose MPC protocols (see, e.g., [25], [24], [3]) opened up the way to advanced applications, e.g. to privacy-preserving data mining [43]. See also [54] for an overview of applications of MPC. Privacy-preserving reputation systems only address half of our requirements (posting a public, yet anonymous, order, e.g. a rating of a service provider [67]), but not the other half (personally accruing the order's revenues).

SNARKs. The influential work of Micali on computationally sound proofs [49] gave the first zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) for all of NP, relying on the random oracle heuristic [5]. Later work (starting with [23], [13]), showed that zk- SNARKs exist in the standard model, based on so-called knowledge-of-exponent assumptions; interestingly, these type of assumptions seem to be inherent for constructing zk-SNARKs [28]. An overview of these (and more) results can be found in [65]. In terms of implementation, the most efficient ones include [8], [10], [55].

XV. CONCLUSION

This description shows the first practical realization of distributed, secure, full financial intermediation without a trusted third party. Our chosen example has been one of the landmark institution of financial intermediation: a Futures Market Exchange. Besides the practical relevance of the application, such realization was interesting from a security perspectives as it requires to provide a rich security functionality with varied and potentially conflicting requirements. One needs to support a public availability of information about all actions performed by traders in the market (such as post or cancel orders) as well as public verifiability of integrity of private information from the traders. Further we need to provide participants anonymity and public unlinkability together with global integrity guarantees and private linkability.

Our analysis of actual trading days using the Thomson-Reuters database, including a complete trading history at the level of milliseconds, have shown that the computation behind our protocol is within engineering reach: we simulated that on a low frequency market a secure protocol using a normal server (as opposed to traders' typical supercomputers) could still be executed within a day with an handful of exceptions. There are interesting avenues of future research. The first open issue is the choice of majority for the distributed consensus protocol. These solutions need further validation by financial economists: majority of traders or by weighted volumes? Should traders making offers far from the market price be considered as their offers might never be executed? Another direction is to further analyze the liveliness and robustness of our protocol against collusion and price discrimination. To avoid complications, our protocol by default goes to mark-to-market upon failure. Alternatives are possible, e.g. margin-call for additional funds.

In terms of practical implementation, we found the zk-SNARKs library to be pretty scalable, whilst the SPDZ library of our unoptimized implementation hit a hard limit at 10 traders due to the dynamic memory requirements (with the natural encoding of SHA256 in Python). This was surprising, as the final size of SPDZ bytecode was acceptable and consistent with the results from the literature [25].

REFERENCES

[1] F. Allen and A. M. Santomero, The theory of financial intermediation," J. of Banking & Fin., vol. 21 , no. 11-12, pp. 1461 - 1485, 1997.

[2] M. Alsabah and I. Goldberg, "Performance and security improvements for tor A survey," ACM Comput. Surv., vol. 49, no. 2, pp. 32:1-32:36, 2016.

[3] D. W. Archer, D. Bogdanov, B. Pinkas, and P. Pullonen, "Maturity and performance of programmable secure computation," Proc. of IEEE SSP, vol. 14, no. 5, pp. 48-56, 2016.

[4] F. Baldimtsi and A. Lysyanskaya, "Anonymous credentials light," in Proc. of ACM CCS, 2013, pp. 1087-1098.

[5] M. Bellare and P. Rogaway, "Random oracles are practical: A paradigm for designing efficient protocols," in Proc. of ACM CCS, 1993, pp. 62-73.

[6] M. Ben-Or, S. Goldwasser, and A. Wigderson, "Completeness theorems for non- cryptographic fault-tolerant distributed computation (extended abstract)," in Proc. of ACM STOC, 1988, pp. 1-10.

[7] E. Ben-Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, and M. Virza, "Zerocash: Decentralized anonymous payments from bitcoin," in Proc. of IEEE SSP, 2014, pp. 459-474.

[8] E. Ben-Sasson, A. Chiesa, D. Genkin, E. Tromer, and M. Virza, "Snarks for C: Verifying program executions succinctly and in zero knowledge," in Proc. of CRYPTO, 2013, pp. 90- 108.

[9] E. Ben-Sasson, A. Chiesa, M. Green, E. Tromer, and M. Virza, "Secure sampling of public parameters for succinct zero knowledge proofs," in Proc. of IEEE SSP, 2015, pp. 287-304.

[10] E. Ben-Sasson, A. Chiesa, E. Tromer, and M. Virza, "Succinct noninteractive zero knowledge for a von neumann architecture," in Proc. of USENIX Security, 2014, pp. 781-796.

[11] R. Bendlin, I. Damg°ard, C. Oriandi, and S. Zakarias, "Semihomomorphic encryption and multiparty computation," in Proc. of Int. Conf. on the Theory and App. of Crypto. Tech., 2011, pp. 169-188.

[12] D. Bemhard and B. Warinschi, "Cryptographic voting - A gentle introduction," in FOSAD, 2013.

[13] N. Bitansky, R. Canetti, A. Chiesa, and E. Tromer, "From extractable collision resistance to succinct non-interactive arguments of knowledge, and back again," in Innov. in Theor. Comp. Set., 2012, pp. 326-349.

[14] F. Boudot, "Efficient proofs that a committed number lies in an interval," in Proc. of EUROCRYPT, 2000, pp. 431-444.

[15] N. Brady, N. Carey, W. Erwin, J. Gilmore, M. Quattrocki, F. Stone, and M. Thomburgh, "Network and method for trading derivatives," Feb. 26 2008, uS Patent 7,337,140. [Online]. Available: https://www.***.ch/patents/US7337140

[16] J. Camenisch, R. Chaabouni, and A. Shelat, "Efficient protocols for set membership and range proofs," in Proc. of ASIACRYPT, 2008, pp. 234-252.

[17] R. Canetti, "Universally composable security: A new paradigm for cryptographic protocols," in Proc. of IEEE FOCS, 2001 , pp. 136-145.

[18] R. Canetti, Y. Lindell, R. Ostrovsky, and A. Sahai, "Universally composable two-party and multi-party secure computation," in Proc. of ACM STOC, 2002, pp. 494-503.

[19] M. Castro and B. Liskov, "Practical byzantine fault tolerance and proactive recovery," ACM TOCS, vol. 14, no. 5, pp. 398-461 , 2002.

[20] D. Chaum, C. Cr^'epeau, and I. Damg°ard, "Multiparty unconditionally secure protocols (extended abstract)," in Proc. of ACM STOC, 1988, pp. 11-19.

[21] J. Clark, J. Bonneau, E. W. Felten, J. A. Kroll, A. Miller, and A. Narayanan, "On decentralizing prediction markets and order books," in WEIS, 2014.

[22] CoinDesk, "Understanding the dao attack," http://www.coindesk.com/understanding-dao hack-journalists/, 2016.

[23] I. Damg°ard, S. Faust, and C. Hazay, "Secure two-party computation with low communication," in Proc. of TCC, 2012, pp. 54-74. [24] I. Damg°ard, M. Keller, E. Larraia, V. Pastro, P. Sertoli, and N. P. Smart, "Practical covertly secure MPC for dishonest majority - or Breaking the SPDZ limits," in Proc. of ESORICS, 2013, pp. 1-18. 38

[25] I. Damg°ard, V. Pastro, N. Smart, and S. Zakarias, "Multiparty computation from somewhat homomorphic encryption," in Proc. of CRYPTO, 2012, pp. 643-662.

[26] Ethereum, "A next-generation smart contract and decentralized application platform,"

2015.

[27] Futures Industry Association, "Largest derivatives exchanges worldwide in 2015, by number of contracts traded (in millions)," 2016.

[28] C. Gentry and D. Wichs, "Separating succinct non-interactive arguments from all falsifiable assumptions," in Proc. of ACM STOC, 2011 , pp. 99-108.

[29] P. Ginsberg and T. Heaton, "Futures contract on options contracts exchange device," Apr. 27 2010, uS Patent 7,707,096. [Online]. Available: http://www.***.ch/patents/US7707096 [30] O. Goldreich, Foundations of Cryptography - Volume 2: Basic Applications. Cambridge University Press, 2004.

[31] O. Goldreich, S. Micali, and A. Wigderson, "How to play any mental game or A completeness theorem for protocols with honest majority," in Proc. of ACM STOC, 1987, pp. 218 -229.

[32] M. Grubb, A. Keijsers, and P. McConnell, "Real time trading," Feb. 6 2014, uS Patent App. 14/039,757. [Online]. Available: https://www.***.com/patents/US20140040101

[33] L. Harris, Trading and exchanges: Market microstructure for practitioners. Oxford University Press, 2003.

[34] J. Hull, S. Treepongkaruna, D. Corwell, R. Heaney, and D. Pitt, Fundamentals of futures and options markets. Pearson H. Edu, 2013.

[35] Y. Ishai, J. Katz, E. Kushilevitz, Y. Lindell, and E. Petrank, On achieving the "best of both worlds" in secure multiparty computation," SIAM J. on Comp., vol. 40, no. 1 , pp. 122-141 , 2011.

[36] A. Kiayias, T. Zacharias, and B. Zhang, "An efficient e2e verifiable e-voting system without setup assumptions," IEEE S&P Mag., 2016.

[37] A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou, "Hawk: The blockchain model of cryptography and privacy-preserving smart contracts," in Proc. of IEEE SSP, 2016, pp. 839- 858.

[38] A. E. Kosba, Z. Zhao, A. Miller, Y. Qian, T. H. Chan, C. Papamanthou, R. Pass, A. Shelat, and E. Shi, "How to use snarks in universally composable protocols," IACR Crypto. ePrint Ar., vol. 2015, 2015.

[39] R. Kumaresan, T. Moran, and I. Bentov, "How to use bitcoin to play decentralized poker," in Proc. of ACM CCS, 2015, pp. 195-206.

[40] R. Kumaresan, V. Vaikuntanathan, and P. N. Vasudevan, "Improvements to secure computation with penalties," in Proc. of ACM CCS, 2016, pp. 406-417.

[41] J. Labuszewski, J. Nyhoff, J. Boudreault et al., "Disseminating floor quotes from open outcry markets," Oct. 23 2013, uS Patent App. 14/061 ,286.

[42] Y. Lindell, "How to simulate it - A tutorial on the simulation proof technique," IACR Crypto. ePrint Ar., vol. 2016, p. 46, 2016.

[43] Y. Lindell and B. Pinkas, "Secure multiparty computation for privacypreserving data mining," IACR Crypto. ePrint Ar., vol. 2008, 2008.

[44] K. Malinova, A. Park, and R. Riordan, "Do retail traders suffer from high frequency traders," Available at SSRN, vol. 2183806, 2013.

[45] J. W. Markham, "Manipulation of commodity futures prices-the unprosecutable crime," Yale J. on Reg., vol. 8, p. 281 , 1991.

[46] J. M. Marynowski, C. D. Voinescu, S. Puscasu, and T. M. O'donnell, "Automated trading system in an electronic trading exchange," May 13 2014, uS Patent 8,725,621. [Online]. Available: http://www.***.com/patents/US8725621

[47] F. Massacci, C. N. Ngo, J. Nie, D. Venturi, and J. Williams, "The seconomics (security- economics) vulnerabilities of decentralized autonomous

organizations," in Proc. of SPW, 2017, pp. 171-179.

[48] R. C. Merkle, "A digital signature based on a conventional encryption function," in Proc. of CRYPTO, 1987, pp. 369-378.

[49] S. Micali, "Computationally sound proofs," SIAM J. on Comp., vol. 30, no. 4, pp. 1253- 1298, 2000.

[50] I. Miens, C. Garman, M. Green, and A. D. Rubin, "Zerocoin: Anonymous distributed e-cash from bitcoin," in Proc. of IEEE SSP, 2013, pp. 397-411.

[51] M. Morano, I. Wall, S. Gaer, and K. Neumann, "Distributed trading bus architecture," Feb. 15 2011, uS Patent 7,890,412.

[52] S. Nakamoto, "Bitcoin: A peer-to-peer electronic cash system," 2008.

[53] J. B. Nielsen, P. S. Nordholt, C. Oriandi, and S. S. Burra, "A new approach to practical active-secure two-party computation," in Proc. Of CRYPTO, 2012, pp. 681-700.

[54] C. Oriandi, "Is multiparty computation any good in practice?" in IEEE ICASSP, 2011, pp.

5848-5851. [55] B. Pamo, J. Howell, C. Gentry, and M. Raykova, "Pinocchio: nearly practical verifiable computation," ACM Comm., vol. 59, no. 2, pp. 103- 112, 2016.

[56] C. Pirrong, The economics of clearing in derivatives markets: Netting, asymmetric information, and the sharing of default risks through a central counterparty," Asym. Info., & the Sharing of Default Risks Through a Central Counterparty, 2009.

[57] T. Rabin and M. Ben-Or, "Verifiable secret sharing and multiparty protocols with honest majority (extended abstract)," in Proc. of ACM STOC, 1989, pp. 73-85.

[58] K. Sako, "An auction protocol which hides bids of losers," in Pub.-Key Crypto., 2000, pp.

422-432.

[59] T. Sander and A. Ta-Shma, "Auditable, anonymous electronic cash," in Proc. of IEEE ICC, 1999, pp. 555-572.

[60] D. F. Spulber, "Market microstructure and intermediation," J. of Econ. Persp., vol. 10, no. 3, pp. 135-152, 1996.

[61] US CFTC, "Mission & responsibilities," 2016.

[62] U.S. Securities and Exchange Commission, "Concept release on equity market structure," Release No. 34-61458; File No. S7-02, vol. 10, 2010.

[63] M. Vukoli^'c, The quest for scalable blockchain fabric: Proof-of-work vs. bft replication," in iNetSec, 2016, pp. 112-125.

[64] S. Wagner, "Automated futures trading exchange," Feb. 20 1990, uS Patent 4,903,201. [Online]. Available: http://www.***.ch/patents/US4903201

[65] M. Walfish and A. J. Blumberg, "Verifying computations without reexecuting them," ACM Comm., vol. 58, no. 2, pp. 74-84, 2015.

[66] A. C. Yao, "Protocols for secure computations (extended abstract)," in Proc. of IEEE FOCS, 1982, pp. 160-164.

[67] E. Zhai, D. I. Wolinsky, R. Chen, E. Syta, C. Teng, and B. Ford, "Anonrep: Towards tracking-resistant anonymous reputation." 2016, pp.583-596.

Appendix

A. Supporting Material: Protocol Construction

Fig. 19 provides the formal description for Πρ,* and llget whereas Fig. 20 contains a formal description of our protocol.

B. Supporting Material: Security Analysis

Theorem 1 in section X states the security of our protocol Πο™ from section IX. Below, we formalize security in the stand-alone setting with a malicious adversary. We refer to [30, 42] for a more extensive discussion of the standard formal definitions.

Proof. It is clear that IIDFM computes FCFM- We proceed to prove the security of IIDFM. Let A be a non-uniform deterministic PPT adversary. The simulator S is given access to the ideal functionality FCFM, and can also read the stored/updated values of the corrupted traders (that A controls) from FCFM; recall that, since we prove only static security, the set of corrupted traders I is fixed before the protocol execution starts.

Sub-routines. To simplify the simulator's description, we introduce sub-routines as

well as

that will call Sput, Sget when it is related to commit and retrieve of inventories. The sub-routines will be later invoked by S; while reading them, think of the simulator's behaviour as a simulation strategy for the corresponding protocols

and Each sub-routine invokes A and receives messages from it. The

subroutines use Sget and Spu above. Note that, since we are working in the hybrid model, whenever A interacts with an ideal functionality the simulator receives A's inputs to the functionality in the clear, and thus it can perfectly emulate the output of the hybrid functionality. Sput: When a trader Pi commits to an inventory, it acts as a prover while the other traders act as verifiers. If Pi is corrupted, S needs to simulate the views of both the prover Pi and the corrupted verifiers P_j, by receiving the inputs from Pi and forwarding them to each corrupted verifier P^. Otherwise, S only needs to simulate the view of the corrupted verifiers P_j, by forwarding [0]] and p = Add(T , [OB) to each corrupted verifier P_j . In both case S simulates the output of for each corrupted players, abort the simulation if any check fails.

When a trader Pj needs to be checked for a non-negative instant net position, it acts as a prover while the other traders act as verifiers. The steps are also similar to Spu, but with F"*,

When a trader Pj posts an order, it acts as a prover together with some other trader P_r with a matching order, while the other traders act as verifiers. We distinguish four cases for the honesty of Pi and P_r. The steps are also similar to Sput but with and

Simulator description. We are now ready to describe the simulator. In each round t≤ T, the simulator S runs as follows depending on the current phase the protocol.

Initialization: Let Pi be the trader committing to a good inventory. If Pi is corrupted: 1. Receive the commitments of inventory values and [TpD from obtain the inputs that A sends to

and

and simulate the output of such ideal functionalities for each corrupted trader in I.

2. Forward (init, Pi.mp]) to FCFM; if the ideal functionality returns 0 simulate an abort of the protocol.

3. Receive the decommitments corresponding to

and simulate an abort of the protocol in case such values are not valid

openings.

4. Run Sput (for the case of corrupted Pi).

If Pi is honest we proceed as follows.

1. Forward commitments to zero for each of the values broadcast by Pi in the first step of the initialize phase; obtain the inputs that A sends to and and simulate the

output of such ideal functionalities for each corrupted trader in I.

2. Open the commitments to zero corresponding to

3. Run

Post/Cancel Order. Let Pi be the trader posting an order or canceling a previous order. We distinguish two cases for Cancel Order and 4 cases for Post Order. If Pi is corrupted::

1. In case of Post Order, receive the values (1 , 1, v) and [i]] from P^ forward (post order, Pi,

If Pi is honest: we proceed as follows.

If Pj is honest and P_r is corrupted (or viceversa): proceed as above, depending on who is honest/corrupted.

Margin Settlement Note that during this phase S always leams the list of pending orders that are canceled, as a public output of FCFM- If Pi is corrupted we proceed as follows. 1. For each order to be canceled in an unspent inventory:

a. Receive the values t' and (-1 , 1, v) from Pi; obtain the inputs that A sends to F⁰⁰, and simulate the output of such ideal functionality for each corrupted trader in I. b. Run Svaid and Sn* (for the case of corrupted Pi).

c. Obtain the inputs that A sends to Fcnpare. and simulate the output of such ideal functionality for each corrupted trader in I.

2. For each broke unspent inventory:

a. Run

and

(for the case of corrupted Pi).

b. Obtain the inputs that A sends to and simulate the output of such ideal

functionality for each corrupted trader in I.

c. Run S (for the case of corrupted Pi).

If Pj is honest: Same as above, except that the values (I, v') for each order to be canceled are obtained from FCFM-

Mark To Market. Let Pi be the trader committing to a good inventory with marked-to-market values. If Pi is corrupted:

1. Run Sget (for the case of corrupted Pi).

2. Receive the commitments and obtain the inputs that A sends to F"*"¹, and simulate the output of such ideal functionality for each corrupted trader in I.

3. Run Sput (for the case of corrupted Pi).

If P) is honest: Proceed as follows.

1. Run Sget (for the case of honest Pi).

2. Forward commitments to zero for each of the values broadcast by Pi in the second step of the Mark to Market phase; obtain the inputs that A sends to F"*"¹, and simulate the output of such ideal functionality for each corrupted trader in I.

Run Sput (for the case of honest Pi).

Indistinguishabilrty of the simulation.

We need to show that for all PPT adversaries A, all I <= [N], and every auxiliary input z ε {0, 1}*, the following holds:

We start by considering a hybrid experiment HYBRID1 with a simulator S1 that runs exactly the same as S, except that S1 also plays the role of the ideal functionality FCFM on its own. This means that S1 directly receives the inputs of other honest traders that are not under control of A. Clearly, for all adversaries A, all subsets I, and every auxiliary in put z E {0, 1}* , we have that

, as there is no difference in generating the view of A in the two experiments. Next, we consider another hybrid experiment HYBRID2 with a simulator S2 that runs exactly the same as S1 , except that whenever S1 commits to zero values when dealing with dishonest verifiers, S2 commits to the real values received from the honest provers. The lemma below shows that the two experiments are statistically close.

Lemma 1. For all (unbounded) adversaries A, all I <= [N], and every z ε {0, 1}*:

Proof. The proof is down to the statistical hiding property of the non-interactive commitment Com. We consider a variant of the statistical hiding property where a distinguisher D is given access to a left-or-right oracle 0*(b, ·), parametrized by a bit b 6 {0, 1}, that upon input v ε {0, 1}* returns [v]] (if b = 0) or [0]] (if b = 1), where |0| = |v|; hence, we have Com is statistically hiding if for all computationally unbounded D,

for a negligible function v: N→ [0, 1]. By a standard hybrid argument, as long as D makes a polynomial (in λ) number of oracle queries, the above flavor of statistical hiding is equivalent to that of Com.

Assume there exists a distinguisher D' and a polynomial ρ(λ), such that, for some I <= [N] and z E {0, 1}*, and for infinitely many values of λ e N, we have that

^

We can construct a distinguisher D breaking the statistical hiding property of Com as follows. D runs A and simulates an execution of protocol ΠΟΗΜ exactly as S1 does, except that whenever S1 forwards a commitment to zero, D asks a query to the left-or-right oracle and sends the output of the oracle to A; the value v for each oracle query is equal to the value S2 would commit to (instead of committing to zero). In case D receives always commitments to zero, the view of A when run by D is identical to the view in the first hybrid experiment; on the other hand, in case D receives always commitments to the values queries to the left-or-right oracle, the view of A when run by D is identical to the view in the second hybrid experiment. Thus, D retains the same advantage of D'. This concludes the proof.

The lemma below says that the view of the adversary in the last hybrid experiment is computationally indistinguishable from the view in the real experiment.

Lemma 2. For all PPT adversaries A, it is

Proof. Fix I <= [N], and z 6 {0, 1}*. Consider the following events, defined over the probability space of the last hybrid experiment.

Event Bad_lnv: The event becomes true whenever A can modify the inventory of a corrupted trader Pi, by finding two distinct valid openings for a token Tp]. The computational binding property of Com implies that Pr [Bad_hy| is negligible.

Event Badspencj: The event becomes true whenever A can double spend the inventory of a corrupted trader Pi, by finding two distinct valid openings for [Tp]]. The computational binding property of Com implies that Pr [Bad_hy| is negligible.

Event Badfoige: The event becomes true whenever A forges an inventory of a trader Pi, by finding two distinct valid authentication paths for a leaf [Tp]] of the Merkle Tree. The computational binding property of the Merkle Tree, which follows from the collision resistance of the underlying hash function, implies that PrfBad_fbige] is negligible.

Event Badswapi The event becomes true whenever A claim a pending order of an honest trader P_r, by finding two valid openings for the commitment Hi']]. The computational binding property of Com implies that

Pr[Bads*ap] is negligible.

Define It is not hard to see that conditioning on

Bad not happening, the view of A is identical in the two experiments. This is because the only difference between the last hybrid and the real experiment is that in the former experiment the values m[i], vp], m[i], vp], cp], f[bad]p], f[del][i], f[out]p] are read from the internal storage of S2 (playing the role of FCFM), whereas in the latter experiment these values are specified by the attacker. Hence, by a standard argument, for all PPT distinguishers D:

The proof of the lemma now follows by a union bound.

Combining the above two lemmas, we obtain that the real and ideal experiment are computationally close, as desired.

To estimate the burden of computation, 5 we observe that the summary of each data point from the

THTR is described by a tuple (d, n_p, n_c, n_m, nO where:

• d is the trading date,

• n_p is the number of post orders (# increases),

• n_c is the number of cancelled orders (# decreases),

• n_m is the number of matched orders (# actual trades),

• and nt is the number of traders.

As the plain implementation cannot go beyond 10 traders we have assumed that only 10 traders could actually participate (so we cap r> at 10). With this cap made, we estimate the required computation in a naive MPC implementation according to Fig. 15 as follows.

• For Post/Cancel Order, an order requires 3 sub-steps per trader which yields 3n_t sub- steps to process an order.

• Similarly, for Match Order, an order requires 2 sub-steps per trader hence 2n_t sub- steps to match a trade.

• In each sub-step, one phase must walk through np/2 orders in average (These operations contribute to most of the generic MPC overhead).

They are then multiplied by the time T^mpc(n_t) required by the elementary MPC operation Foe. Differently, while generic MPC requires all traders to compute for one trader, the hybrid protocol allows traders to produce and verify the proof by themselves at the same time so the cost is not affected by The proof generation time and the proof verification time τ^^,τ^ are actually performed by different traders. This is not important to calculate the overall crypto- overhead of operating the market in a distributed fashion (before moving to the next order both operations must be done) but will be important for the calculation of the proportional burden. Therefore the total time to process a trading day d reported in Fig. 20 of the single trader follows the equations below:

and similarly for the optimized version where the costs have estimated according to Table XII To estimate the fraction of retail and institutional traders p_t we use the data from [41] as well as the fraction of orders performed by retail traders p₀ (pt = 0.71, p₀ = 0.18). Albeit TSX and CME are different exchanges, the skeweness against retail traders might be even more pronounced the more active the market For the MPC naive computation a party has to participate to the computation irrespectively to whether she actually made any order. So the overall burden of computation by retail traders for naive MPC (Fig. 18 is as follows:

In the hybrid approach, a retail trader only needs to verify proofs when an institutional trader has to generate proof, hence the computation by retail traders (Fig. 21) is determined by the following equation:R

SUBSTITUTE SHEET (RULE 26) 65

SUBSTITUTE SHEET (RULE 26)

Claims

1. A secure transaction system for a plurality of users, comprising

a network comprising a plurality of nodes;

wherein at least some of the public data and at least some of the private data of the users are mutually dependent, such that a change in said at least some of the public data affects correct value(s) for at least some of the private data and such that a change of said at least some of the private data affects correct value(s) for said at least some of the public data; each user device is configured to perform a cryptographic process in dependence on data from its associated private ledger and data from the public ledger to generate cryptographically secure data item(s) that are processable by the other user devices to determine a property of the user and/or a transaction that the user desires or is offering to perform or has performed;

wherein the cryptographic process is such that the cryptographically secure data item(s) is verifiable by the other user devices without determining values of at least some of the data of the private ledger of the user and/or without determining the identity of the user.

2. The secure transaction system of claim 1 , wherein the public data at least one of:

a) comprises data to which all of the users are permitted access,

b) comprises, or is representative of, or is obtained by processing, data obtained from a plurality of the users

c) comprises or is representative of an aggregation of data from a plurality of the user devices.

3. The secure transaction system of any preceding claim, wherein the cryptographically secure data item(s) comprises certified data item(s).

4. The secure transaction system of any preceding claim, wherein the verifying of the cryptographically secure data item(s) by the other user devices comprises decrypting the cryptographically secure data item(s).

5. The secure transaction system of any preceding claim, wherein the verifying of the cryptographically secure data item(s) by the other user devices comprises determining that the data item(s) are valid.

6. The secure transaction system of any preceding claim, wherein the verifying of the cryptographically secure data item(s) by the other user devices comprises determining that the data item(s) are valid in accordance with a cryptographic protocol.

7. The secure transaction system of any preceding claim, wherein the cryptographically secure data item(s) are verifiable by the other user devices without determining values of at least some of the data of the private ledger of the user that was used to generate the secure data item(s) and/or without determining the identity of the user.

8. The secure transaction system of any preceding claim, wherein the cryptographically secure data item(s) are processable by the other user devices to determine a commitment and/or a buy or sell order, without determining from which user or user device the commitment and/or buy or sell order originated and without revealing other commitments and/or buy or sell orders issued by the user or user device and without revealing a status of at least one.

9. The secure transaction system of any preceding claim, wherein the secure data item(s) are such that user identity or user device identity is not determinable by the other user devices by processing the cryptographically secure data item(s) generated by the user device.

10. The secure transaction system of any preceding claim, wherein each cryptographically secure data items comprises a zero knowledge proof.

11. The secure transaction system of any preceding claim, wherein the encryption process is such that if the transaction that is desired or being offered by the user is not valid, then the cryptographic process will fail.

12. The secure transaction system of any preceding claim, wherein the encryption process is such that if the version of the public ledger that the user device bases the encryption process upon is different to a version of the public ledger used by another of the user devices then said other of the user devices the cryptographically secure data item will be rejected or determined to be invalid by said other of the user devices.

13. The secure transaction system of any preceding claim, wherein the encryption process is such that if the transaction that is desired or being offered by the user is not valid, then the corresponding cryptographically secure data item(s) is processable by the other user device(s) to determine that the transaction is invalid and/or is such as to be rejected by the other user devices.

14. The secure transaction system of any preceding claim, wherein the public ledger and/or multiple versions of the public ledger are stored jointly or separately by, or under control of, the plurality of user devices.

15. The secure transaction system of any preceding claim, wherein the public ledger comprises a distributed ledger.

16. The secure transaction system of any preceding claim, wherein the public ledger comprises a block chain-based distributed ledger.

17. The secure transaction system of any preceding claim, wherein the user devices are configured to, in response to a cryptographically secure data item(s) from another of the user devices determine that the cryptographically secure data item(s) represent a valid transaction and update the public ledger with said valid transaction.

18. The secure transaction system of any preceding claim, wherein the plurality of user devices are configured to distribute public ledger updates thereby to maintain up-to-date version(s) of the public ledger.

19. The secure transaction system of any preceding claim, wherein the transactions comprise at least one of a buy order, a sell order.

20. The secure transaction system of any preceding claim, wherein the transactions comprise transactions performed in respect of at least one asset or a derivative thereof.

21. The secure transaction system of any preceding claim, wherein the asset(s) comprises at least one of a stock, bond, currency, physical asset or a financial instrument derived therefrom.

22. The secure transaction system of any preceding claim, wherein the secure transaction system is operable to provide a market, and the users comprise market participants.

23. The secure transaction system of any preceding claim, wherein the public ledger comprises a representation of a state of the market.

24. The secure transaction system of any preceding claim, wherein the public ledger comprises a representation of a collection of transactions proposed, variously, by or otherwise associated with a plurality of the users or all of the users.

25. The secure transaction system of any preceding claim, wherein the public ledger comprises or is representative of or is processable to determine transactions available to the users.

26. The secure transaction system of any preceding claim, wherein each user device is configured to perform a transaction and to update the public ledger and its private ledger in view of the transaction.

27. The secure transaction system of any preceding claim, wherein each user device is configured to transmit a message, representative of the transaction and/or representative of a state of the market after the transaction.

28. The secure transaction system of any preceding claim, wherein the user devices are configured to transmit messages and/or data and/or ledger updates in the form of blocks according to block-chain protocol.

29. The secure transaction system of any preceding claim, wherein each user device stores or is associated with at least one of a financial account, a margin account, an asset holding account or other account.

30. The secure transaction system of any preceding claim, wherein the cryptographic process is such that, and/or the user device is configured to apply market rules such that, generation of the cryptographically secure data item(s) in respect of a transaction desired by a user is rejected or prevented or otherwise not allowed by the user device if the transaction would be against a market rule and/or would cause at least one of the account(s) to fall below a pre-determined threshold amount and/or would cause a user to pass through a pre-determined risk management threshold.

31. The secure transaction system of any preceding claim, wherein each user device comprises a processing resource.

32. A device for performing secure transactions comprising:

a processing resource and a communication interface for communicating with at least one further device;

the device further comprising, and/or the processing resource being configured to communicate with, at least one data store;

wherein the at least one data store stores a private ledger containing private data associated with a user, the at least one data store stores public data, wherein the public data is representative of, or processable, to determine, transactions that are available to users;

at least some of the public data and at least some of the private data of the users are mutually dependent, such that a change in said at least some of the public data affects correct value(s) for at least some of the private data and such that a change of said at least some of the private data affects correct value(s) for said at least some of the public data;

wherein the processing resource is configured to perform a cryptographic process in dependence on data from its associated private ledger and data from the public ledger to generate cryptographically secure data item(s) that are processable by other user devices to determine a property of the user and/or a transaction that the user desires or is offering to perform or has performed;

33. The device of claim 32, wherein the processing resource of the device is configured to receive a cryptographically secure data item(s) from at least one other user device and to process said cryptographically secure data item(s) to determine a property of another user and/or a transaction that said another user desires or is offering to perform or has performed.

34. A system comprising a plurality of user devices of claim 32 or 33, and a network configured to provide communication between said plurality of user devices.

35. A method for performing a secure transaction comprising performing a cryptographic process in dependence on data from a private ledger associated with a user and data from a public ledger to generate cryptographically secure data item(s) that are processable by other users devices to determine a property of the user and/or a transaction that the user desires or is offering to perform or has performed, wherein at least some of the public data and at least some of the private data of the users are mutually dependent, such that a change in said at least some of the public data affects correct value(s) for at least some of the private data and such that a change of said at least some of the private data affects correct value(s) for said at least some of the public data.

36. A computer program product comprising computer readable instructions that are executable by a processor or processors to perform a method of claim 35.