Initial Public Offering (IPO) on Permissioned Blockchain using

Secure Multiparty Computation

Fabrice Benhamouda∗1, Angelo DeCaro†1, Shai Halevi‡1, Tzipora Halevi§2, Charanjitjutla¶1, Yacov Manevich‖1, and Qi Zhang∗∗1

1IBM Research2Brooklyn College

October 22, 2018

Abstract

In this work, we add secure multiparty computationcapabilities to the permissioned blockchain architec-ture of Hyperledger Fabric, and use them to imple-ment the clearing price mechanism for IPOs. Fabricis a platform for “blockchain for business,” providinga robust mechanism for a set of “peers” to jointlymaintain a distributed immutable ledger. As withany blockchain, using confidential data on the ledgeris a challenge, and we use cryptographic secure multi-party computation (MPC) to address this challenge.The use of secure MPC to enable confidential data onblockchains was proposed before, but this approachonly now begins to find its way to real-life systems.In particular, ours is the first attempt to integrate itin a complex blockchain environment such as Fabric.

To enable this approach, we integrated mechanismsinto Fabric to let the peers access local informationsuch as their respective keys, and also send messagesto each other while executing smart contracts. Weadded to Fabric a library that implements the re-

∗fabrice.benhamouda@normalesup.org†adc@zurich.ibm.com‡shaih@alum.mit.edu§thalevi@nyu.edu¶csjutla@us.ibm.com‖yacovm@il.ibm.com∗∗q.zhang@ibm.com

quired cryptographic tools, and made it accessiblefrom the smart contract. We then designed an ef-ficient cryptographic protocol for the IPO clearingprice mechanism, and used our integrated system torun it on Fabric. Although not fully optimized yet,the performance of the resulting implementation ismore than fast enough for this particular application,ranging from 8 to 23 seconds to execute an IPO sale.

1 Introduction

Blockchain technology saw explosive growth over thelast few years. Far beyond just digital currencies,blockchain is often touted as a revolution that is“Changing Money, Business, and the World” [13].At its core, a blockchain is a distributed architecturefor “agreeing on things”: It provides an immutableappend-only shared ledger, allowing multiple entitiesto access the ledger and ensuring that they all agreeon its content, without having to rely on any singletrusted party. The “things” on the ledger are recordsof transactions, and applications that use blockchainmust come with some logic to determine what con-stitutes a transaction, and what records are storedon the ledger. Blockchains come in two flavors, pub-lic (premissionless) or private (permissioned), in thecurrent work we focus on the latter, where direct ac-cess to the ledger is controlled and is often limited to

1

a small set of parties.The core principle that everyone must see the same

ledger, makes it challenging to handle transactionsthat depend on confidential data. But there aremany use-cases that can benefit from using confi-dential data on the ledger (Some are described in[18, 10, 3]). One example is a consortium of hospitalsthat set up a blockchain to record patient treatment,for purposes of audit and compliance. The data it-self must be kept confidential to a single hospital, butthere is great value in computing aggregate statisticsacross multiple hospitals to gauge the effectiveness ofdifferent treatment options.

A natural solution for storing confidential data ona blockchain is to write it on the ledger in encryptedform. This way, everyone sees the same ledger, butaccess to the cleartext data requires having the secretkey. This solution, however, still leaves the questionof how to use that confidential data in transactions.In the example from above, imagine that the hospi-tals want to jointly devise a model that predicts theeffect of a certain treatment protocol, how can theyachieve this without trusting a single entity with allthe cleartext data needed to train that model?

An exciting possibility is to use for this purpose thecryptographic technology of secure multiparty compu-tation (MPC). This technology, invented more thanthree decades ago [15, 7], allows a set of mutually sus-picious parties to compute any aggregate function ontheir respective confidential inputs without revealingtheir secrets, just by exchanging cryptographic mes-sages back and forth. Research into efficient secure-MPC protocols has advanced in leaps and boundsin recent years, making them suitable for many real-world applications. The possibility of using secure-MPC for confidential data on a blockchain was notedbefore (e.g., [18, 10, 3]), but it only now begins toenter actual blockchain systems. In this work we usethis solution in Hyperledger Fabric, which is perhapsthe most widely used permissioned blockchain.

Hyperledger Fabric [1] (or just Fabric for short)is an enterprise level permissioned blockchain plat-form, written in Go. The nodes with direct access tothe ledger in Fabric are called peers, and each peerbelongs to some organization. Transactions are orig-inated by clients, who contact the peers to submit a

transaction proposal. The peers then execute a smartcontract — called a chaincode in Fabric — to deter-mine whether or not the transaction should be ac-cepted, and what should be recorded in the ledger.If the chaincode execution is successful, the peer en-dorses the transaction by signing it, and only trans-actions that were endorsed by sufficiently many peerswill be recorded in the ledger. Since the endorsementprocess is when the application logic is executed, werun secure-MPC protocols during endorsement.1

To demonstrate the power of confidential informa-tion on Fabric, we implemented a system for IPOtrading. IPO trading is an example of a clearing priceauction, where a single seller sells multiple shares atthe same price to many buyers. The system that weimplemented supports multiple banks and brokeragefirms, and many investors. They are all treated asclients of the blockchain, and the blockchain itself ismaintained by a small number of organizations , eachwith its own peer(s).2

The life cycle of an IPO begins when a bank listsit publicly on the ledger, specifying a unique ID, theticker (a.k.a., stock symbol), a description, the num-ber of available shares, and the date and time of thesale. Then, brokerage firms can record IPO orders onthe ledger on behalf of investors. Each order includesthe IPO ID, an order ID,3 and the order details inencrypted form. (Specifically, the order details spec-ify how many shares this investor is willing to buy ateach price point.) Later the listing bank invokes thesell-IPO process, and the peers engage in a protocolto determine the clearing price of this IPO, as well asthe share allocation (which investor gets how manyshares). All of these details are written to the ledger(in the clear), and the IPO is marked as “sold.”

1Recording the transaction on the ledger is only done afteranother process, in which it is sent to an ordering service thatbatches transactions into blocks and checks for ordering con-sistency. However, this process is orthogonal to our study, sowe ignore it in this report.

2For example, the organizations running the blockchaincould be the exchange, a regulator, an accounting board, anda consortium of banks.

3In our actual system, the order ID includes the investorID for simplicity. The system can be easily extended to ensureanonymity of the investors as follows: the brokerage firms userandomly-generated ID and keep in a separate private databasethe mapping between order IDs and investors.

2

The use of a blockchain is highly beneficial for thisapplication, since it provides strong traceability andauditability properties at any point of the IPO lifecycle. These advantages, however, can only be re-alized if we can work with confidential orders with-out having to rely on a trusted party. Otherwise wewill need an out-of-band “supervision” of the trustedparty at all times to ensure that no collusion or pricefixing occurs, negating most/all the utility that canbe derived from the blockchain. What is needed is asystem where all the relevant information is recordedon the blockchain, but no single party can ever getaccess to the secret orders (neither before, during,nor even after the sale).

To achieve the security goals above, our system isdesigned in a way that prevents any single organiza-tion or even a collusion of a small number of themfrom learning anything about the orders. Our useof the MPC-over-Fabric architecture to achieve thegoal above is similar to, but not quite the same as,the one described in [3]: One difference is that theentities with the secrets in [3] are the peers them-selves (playing roles of buyers and sellers in auctions),whereas in our system the secrets “belong” to theclients of the blockchain (i.e., the brokerage firms).In our solution, the brokerage firms break their se-crets into shares, so as to ensure that no single peercan see them, and the peers use secure-MPC to per-form computations on these shares without ever re-constructing the original secrets. Our cryptographicprotocol is designed to be efficient for the applicationat hand, and includes novel ideas in its combinationof additive secret-sharing, GMW-style protocol [7] forcomparing integers, and a new offline/online methodfor converting between binary and mod-N shares ofsecrets.

In order to integrate secure computation (and ourprotocol in particular) into Fabric, we provide thechaincode at the different peer with access to theirsecret keys, as well as the ability to communicatewith each other. For the former we used the constructof “decorators” in Fabric, and for the latter we builtchaincode-to-chaincode communication channels overFabric’s peer-to-peer communication infrastructure.We also adapt existing secure-MPC libraries, bothto allow access from within the blockchain, and to

extend them to handle our clearing-price protocol.The rest of the paper is organized as following: Sec-

tion 2 discusses related work; Section 3 describes thedesign of our blockchain based IPO trading system.Details of the MPC protocol used in the system aredescribed in Section 4, performance measurementslisted in Section 5, and conclusions are in Section 6.

2 Related Work

The challenge of using private/confidential informa-tion in blockchain architectures is well recognized,several (partial) solutions are already available, andmore were suggested in the literature.

One partial solution is based on zero-knowledgeproofs (ZKP) [8]. a ZKP is a cryptographic protocolby which one party (a prover) can convince othersthat some statement is true, without revealing anyadditional information. This provides a good solu-tion to cases where a smart contract depends on thesecret data of a single party : The party with the se-cret runs the smart contract on its own, then prove toeveryone else that it did so correctly. For example, ina setting where participants have accounts with secretbalance on the ledger, a participant wishing to buya $100-item can use ZKP to prove that its balance isgreater than $100. This approach is used for examplein the Zcash currency [16], that supports a very gen-eral form of ZKPs. However, ZKPs are not sufficientin settings where the smart contract depends on thesecret information of more than one participant. Forexample, if we have two parties with secret balances,and the smart contract needs to compare them.

Another partial solution in a permissionedblockchain is to partition the ledger into separatechannels (which are essentially different ledgers),thus limiting what each party can see to only thechannels that this party can access. This solution isimplemented in Fabric, but it still requires that allmembers of a channel trust each other with all thedata on this channel.

Below we list some existing blockchain systemsthat we know of, offering support for confidential datain certain settings.

Blockstream Confidential Assets (CA) [14]

3

use simple ZKPs in conjunction with additive homo-morphic commitments to manipulate secret data onthe ledger. For example, two users whose secret ac-count balances are encrypted with additively homo-morphic commitments, can agree privately (off chain)on a price of an item. The first user can then sub-tract this amount from her balance and add it tothe balance of the other user (using homomorphism),and prove to everyone (using ZKP) that the amountadded to the second balance is equal to the amountsubtracted from the first. But note that the trans-action amount itself must be fully known to the firstparty, this combination of ZKP and additively homo-morphic commitments is still not strong enough tocompare two secret values. This combination of ZKPand additive homomorphism, however, is not strongenough to compare two secret values, for example.

Solidus [5] is a system for confidential transactionson public blockchains, aiming to hide not only thedetails of the different transactions but also the par-ticipants in those transactions. Designed for bankingenvironments, it uses publicly-verifiable Oblivious-RAM (which combines ZKPs with Oblivious-RAM)to hide the identities of the individual bank cus-tomers. Similar to other ZKP-based solutions,Solidus is designed for settings where each transac-tion depends only on secrets of one participant (i.e.,one of the banks).

Hawk [10] is an architecture for a blockchain thatcan support private data. It uses a trusted compo-nent (called a manager) to handle that secret data,which is realized using trusted hardware (such as In-tel SGX). The Hawk paper remarks that secure-MPCprotocols can also be used to implement the manager,but chose not to explore that option in their context(with very many parties).

Enigma [18, 19] uses secure-MPC protocols to im-plement support for private data on a blockchain ar-chitecture. The main difference between our solu-tion and Enigma is that we integrate secure-MPCprotocols within the blockchain architecture itself,while Enigma uses off-chain computation for thatpurpose. Some comparison between on-chain and off-chain secure-MPC can be found in [3].

Calcatopia [11] and Tangram [17] These are

new startups that promote the use of secure-MPCwith blockchain architectures (possibly using someoff-chain computations). While the available detailson these systems are scant, they seems to be usingonly two-party secure-computation in their examples.

3 Integration in HyperledgerFabric

Our IPO trading system is integrated into Fabric. Be-low we briefly discuss some relevant aspects of Fabric,then elaborate on our integration work.

3.1 Basics of Hyperledger Fabric

This subsection introduces three critical componentsin Fabric: application chaincode, system chaincode,and peer to peer communication. more details onFabric itself can be found in [1]. Also note that,in Fabric, it is the client’s responsibility to invokenew transactions by contacting one or more peers andsending them a transaction proposal to be endorsed,and all the invoked peers will see exactly the sametransaction details.

Application chaincode. The application chain-code is the program code that implements the ap-plication logic, which runs during the endorsementof transactions. It is the central part of a dis-tributed application in Fabric and may be writtenby an untrusted developer. Currently, the program-ming languages supported for chaincode are Go andJavaScript (running in Node.js runtime). A chain-code needs first to be installed by an administratoron the peers that are supposed to execute it, then itcan be instantiated, making the network aware of it.When a client submits a transaction proposal to thepeers, this transaction references an existing chain-code, to be run for endorsing it.

The chaincode is executed within an environmentwhich is somewhat isolated from the rest of the peer:it is running it in a Docker container and commu-nicating with the peer only using gRPC messagesover mutual TLS. In this way, the peer is agnostic

4

of the actual language in which the chaincode is im-plemented.

System chaincode. In contrast to applicationchaincode, a system chaincode (SCC) runs directlyin the peer process. SCCs are instantiated at peer’sstartup, and have access to all of the peer’s infras-tructure (including direct access to the ledger and thecommunication layer). Fabric comes with a numberof SCCs, providing services to the chaincodes (suchas reading from the ledger), and also validating theirresults. Fabric can also leverage Go plugins to allowa peer’s administrator to embed new functionality byadding SCCs as needed (though we did not use plu-gins in this project).

Peer to peer communication. Peers communi-cate with each other over gRPC channels secured byTLS. Since Fabric is a permissioned blockchain, peershave certificates (signed by the peer’s organization),which are also leveraged for communication securityand identification. Peers can send each other twokinds of messages:

• Point to point: These messages are exchangedbetween peers on both sides of a connection, andare never forwarded further. The communica-tion layer exposes an API to higher layers of thepeer that attaches the sender peer’s enrollmentcertificate for every message sent to the peer, andin this way - an application layer inside the peercan employ this mechanism as well and doesn’tneed to implement its own authentication mech-anism to prevent message spoofing. The Comm-SCC in our study uses this point-to-point mes-saging ability in order to send messages securelyto peers denoted by the caller chaincode.

• Gossiped: These messages are disseminated viaa gossip protocol: when sending a message, itis first signed by the peer’s private key corre-sponding to the enrollment certificate and sent torandom k1 peers, and also periodically k2 peersare selected to pull messages. The membershipview of a peer (the peers a peer knows about) is

built via this mechanism by having peers dissem-inate their enrollment certificates and messagesattesting for their endpoints, as well as channelmembership messages for each channel, that con-tains channel meta-data information such as theledger height of the peer. This mechanism is alsohow blocks are disseminated between peers, withthe slight modification that the peers do not signthe blocks but the ordering service nodes do.

3.2 Our Modifications

System overview. Our system includes a few or-ganization, each one owning a peer (cf. Footnote 2).The system ensures the confidentiality of the orderdetails (how many shares each investor is willing tobuy for each price point), even if all the organiza-tions but one collude to try to obtain some infor-mation about the orders. Figure 1 depict a scenariowith four organizations, but that number can vary.For a specific IPO, each investor can place their or-ders via their brokerage firm’s web server, which actsas a client for the blockchain and encrypts its in-vestor’s orders and stores the encrypted data into theblockchain ledger. When the time for IPO trading ar-rives, the organizations collaborate with each othervia an MPC protocol to compute the clearing price.This computation is done without the decrypted in-formation ever being revealed in the clear, not evento the organizations that participate in the computa-tion.

Integrating secure computation (and our protocolin particular) into Fabric took a significant designand implementation work, below we sketch the majorchanges that we had to implement in order to makeit work. There were three main issues that we neededto resolve in our implementation:

• Letting instances of the chaincode in differentpeers communicate with each other;

• Giving the different chaincode instances theirkeys and letting them know who the other peersare; and

• Using existing secure-MPC libraries from withinFabric.

5

Web Server

CommSCCPeer

ChaincodeMPC

Org0

Org1

Org2

Org3Blockchain ledger

CertificateAuthority

Orderer

Hyperledger Fabric with MPC

Point-to-point channels

CC

gRPC/TLS

End-user (investor / bank admin)

Brokerage firm / bankHTTPs

Figure 1: Architecture overview of blockchain basedIPO trading system with organizations Org0, Org1,Org2, Org3.

We strove to address these issue without drasticchanges to either Fabric’s codebase or the underlyingsecure-MPC libraries. For this we leveraged Fabric’spluggability and existing mechanisms. The detailsare as follows.

Communication channels. The default endorse-ment process in Fabric is stand-alone: the chaincodeinstance at every peer gets the relevant state fromthe ledger, runs on its own, and returns the intendedchanges that needs to be made. In our case, onthe other hand, the instances at different peers haveto communicate with each other, to be able to runsecure-MPC protocols.

As explained above, a chaincode runs in a sepa-rate process within a Docker container environment,which isolates the chaincodes from each other andfrom the peer. The chaincode can only communicatewith the peer it is attached to using gRPC messages.The secure-MPC communication must therefore gothrough the peers themselves. We augmented Fab-ric with an additional SCC, called CommunicationSCC (CommSCC, for short), that gives the appli-cation chaincode limited access to the peer’s built-incommunication layer’s point-to-point messaging API,in order to send and receive messages. Specifically,CommSCC provides the following primitives:

• Send: Sends a payload to a remote peer. Thechaincode must uniquely identify the remote

peer by a predicate, and the SCC buffers themessage internally and sends back an acknowl-edgment to the chaincode.

• Receive: The SCC returns a message from theintended source peer if such message has beenreceived and is waiting in the internal buffer, orwaits a specified amount of time for reception ofa message from the intended source peer.

CommSCC is made available to all chaincodes, accesscan be restricted to avoid abuses, if needed.

One issue that we had to solve is peer discover-ability, namely how to tell the chaincode in one peerwho are the other peers that it needs to communicatewith. In our implementation, we opted for a simplesolution where peer addresses are specified either inconfiguration files or as argument to the chaincode(as part of the transaction proposal), this solutionrequires no code modifications to Fabric.

Private Data. The default execution mode for ap-plication chaincode in Fabric is that different peersrun identical copies of the code. In our case we needsome specialization of the peers, at least enough togive the different peers their secret keys and tell eachpeer how to contact the other peers that participatein this protocol.

We leverage a Fabric internal mechanism calledchaincode input decoration. That mechanism lets thepeer inject inputs to the local copy of the chaincode,in addition to what was supplied by the transactionfrom the client. We implemented a new chaincodeinput decorator, that loads the peer’s secret from thefile system, and, each time a chaincode is invoked, itinjects the peer’s local data (including keys) into theinputs passed to the chaincode.

Because the decorator is essentially customizedcode, it can be perform additional access control aswell. For example, the decorator can pass the peer’ssecret only to specific chaincodes, or only when thechaincode is invoked by a specific user.

Using existing secure-MPC libraries. Most ofthe secure-MPC libraries (including the one that weused) are written for stand-alone applications, rather

6

than to be used as a component in a larger system.We implemented our protocol from Section 4 over thepublicly available GMW-MPC implementation dueto Seung-Geol Choi [6], which is written in C++,but had to modify and improved several aspects ofthat library:

• The original library assumed complete controlover sockets for communication, we had to ab-stract this interface so as to be able to use theFabric communication mechanisms instead.

• We added support for layered MPC computa-tion, where at intermediate points in the com-putation the parties can decide to reveal par-tial outputs, then continue with another GMW-MPC that may depend on the revealed values.This is used for an efficient implementation ofthe binary-search step in our protocol.

• We also augmented the library so we can per-form multiple instances of GMW-MPC in paral-lel, on single-instruction multiple-data (SIMD)circuits. (This feature let us replace the binarysearch step with a more general t-ary search.)

For the pre-computation and use of correlated ran-domness as described in Section 4, we also im-plemented additional protocols beyond just GMW-MPC.

Yet another aspect that we had to resolve is thatthis library (like the vast majority of secure-MPClibraries) is written in C++, while the chaincodethat needs to invoke it is in Go. To integrate them,we used the SWIG library [12] that allows callingC++ code from other languages. Specifically, SWIGwas added to the containers running the applicationchaincode.

Encrypting content on the ledger. Another is-sue that we tackled is how to get the encrypted con-tent on the ledger to begin with. Roughly speaking,the only way to get new content on the ledger in Fab-ric is to include it in a transaction proposal, and allthe peers must see the same proposal. We thereforehad the client (who prepares the transaction, i.e., a

Figure 2: Creating a new IPO

brokerage firm acting on behalf of an investor) sup-plying all the encrypted content. This means thatit encrypted any content that should only be seenby peer j using peer j’s public key. In addition, theclient also encrypted everything under its own key,to make it possible for it to read it back from theledger, mostly for purposes of displaying it in ouruser-interface.

3.3 User Interface

Our blockchain based IPO trading system has banksthat create and sell IPOs, and brokerage firms repre-senting investors who want to buy shares. The userinterface for these entities is implemented on their re-spective web sites, and the corresponding web serversplay the role of clients in the Fabric blockchain archi-tecture.

When creating a new IPO, an administrator at thebank logs into the bank’s web server and fills a formwith all the public IPO parameters. Namely theyspecify a unique ID, the stock ticker symbol, category,description, creation date, sale date and time,and thenumber of available shares for sale. The IPO creationscreen is shown in Fig. 2. The IPO information isthen recorded on the ledger in the clear.

When an investor accesses its account at a broker-

7

Figure 3: List of open IPOs

Figure 4: Submitting a new order

age firm, it see a list all the open IPOs that are avail-able for sale, and can submit an order for any of them(or view its order if it was already submitted). Thisis illustrated in Fig. 3. When submitting an order,the investor in effect specifies a complete histogram,saying how many shares he/she is willing to buy ateach price point. This is done by specifying a set ofprice/volume points, as depicted in Fig. 4. When theinvestor submits the order, the brokerage web-servertranslates it into a complete histogram. then it Thebrokerage firm web server then shares the histogramamong all the peers (as described in Section 4), anduses the public key of each peer to encrypt its share.It also encrypts the entire order under its own secretkey, to be used if the investor later wants to read theorder from the ledger. (For example when clicking onthe “View Orders” button in Fig. 3.)

Finally, a bank administrator will activate the sell-IPO process from the bank web site. This is done by

Figure 5: Selling an IPO

clicking the “Sell IPO” button as seen in Fig. 5. Thebank web server will then invoke the sell-IPO trans-action, which will run the protocol from Section 4.

4 Cryptographic Protocol forIPO Trading

In this section we describe our cryptographic de-sign in some detail: its functionality, the protocolsteps, and its security properties. Some aspects ofthis protocol are novel, in particular its combinationof additive secret-sharing (allowing easy additions ofshared data) with a comparison procedure followingthe GMW style of protocols [7], and offline/online de-sign. While this integer add-and-compare functional-ity was well studied (cf. [4] for example), in this workwe describe novel ideas for implementing it more ef-ficiently, especially with regards to pre-computation(aka “correlated randomness generation”). As thecombination of additions and comparisons that weimplement is quite common in many auction settings,our techniques should also hold in general for otherauctions.

4.1 The Clearing-Price Function

In a typical IPO, the number of shares for sale is pub-lic information (denoted S), and we also assume apublicly known upper bound P on the clearing price.One can also consider a reserve price, i.e. a lower

8

bound on the clearing price, but for ease of exposi-tion we will let that be zero. Investors submit ordersto the system (via a brokerage firm), and then thesystem computes a clearing price, as well as shareallocation (who gets how many shares). An orderis a complete histogram, orderi : [1 . . P ] → N, withorderi(p) the number of shares that investor i wantsto buy at price point p. 4 The clearing price of theIPO is the highest price for which all the shares aresold. Namely, given n orders we need to compute

PriceS,P

(order1, . . . , ordern)

= max{0 < p ≤ P : Vol(p) ≥ S},(1)

where Vol(p) =∑n

i=1 orderi(p) is the total demandof shares at price p. 5 The main security goal is theprivacy of the investors’ orders, making the IPO asealed-bid clearing-price auction. Traditionally, suchauctions are performed by a trusted auctioneer (aconsortium of investment banks in the case of IPOs).The orders in such traditional auctions, however, arecompletely known to the investment banks (and theirinvolved staff). The pitfalls of trusting an auctioneerare well documented [2] and further economic advan-tages of a truly sealed-bid auction for stock-marketsis discussed in [9].

To mitigate such issues, our approach is splittingthe trust : Instead of a single trusted auctioneer,we have a small set of organizations (four of themby default). Each organization owns a peer on theblockchain. The system is set such that no single or-ganization learns anything about the orders, and ittakes a collaboration of all of them to compute theclearing price. The risk of an untrustworthy auction-eer is much reduced, since it takes a collusion of allthe organizations to compromise the orders’ confiden-tiality.

4We assume rational investors, so the orderi’s are all non-increasing functions: the higher the price, the lower the num-ber of shares. Furthermore, price points are assumed to beintegers in [1 . . P ].

5This is not the only way to set the IPO price, but forsimplicity we stick in this work to only that formula.

4.2 The Protocol

We note that our solution is not a “pure peer-to-peer” multiparty protocol among the investors them-selves. While possible in theory, the sheer numberof investors would make such solution infeasible inpractice. Instead, in our solution the investors secret-share their orders among all the peers, and the peersjointly compute the clearing price from their shares.For simplicity, in this initial work we adopt the semi-honest security model, where all peers are assumed tofollow the protocol correctly. The security goal in thismodel is preventing the peers from learning anythingabout the secret orders from the correct protocol ex-ecusion. The protocol proceeds as follow:

Step 1: sharing the orders. The function thatwe compute, i.e., the clearing price from Eq. (1), re-quires many integer additions (to compute Vol(p) =∑

i orderi(p) for every price-point p), and also com-parisons with a publicly known number (to find thehighest p s.t. Vol(p) ≥ S). The GMW secure-MPC protocol [7] forms the basis of our solution.The GMW protocol can be used to securely com-pute any function on confidential inputs owned bydifferent parties without revealing anything but theoutput of the function. However, it requires the com-puted functions to be represented as a boolean cir-cuits, and implementing the integer additions thisway will be rather inefficient. (GMW-style protocolneed as many rounds of communication as the depthof the circuit, which can then become very expensivein our case.) Instead, in our protocol we use addi-tive secret sharing for the additions, then convert thesums to binary representation for the comparisons.

Let n be the number of investors and m the num-ber of peers (where n could be large and m =4 by default). For each price-point p ∈ [1 . . P ],each investor i uses linear secret-sharing to sharethe number orderi(p) among the m peers, modulosome large number N . Specifically, for each pricepoint p, the investor chooses m − 1 random integersRi,1,p, . . . , Ri,m−1,p ∈ [0 . . N − 1], and sets

Ri,m,p := orderi(p)− (Ri,1,p + . . .+Ri,m−1,p) mod N.

(Note that the sum of the Ri,j,p’s equals orderi(p)

9

modulo N). In our implementation we use N = 232,and we assume that N > 2S and also N > 2Vol(p)for every price point p.

The i’th investor sends to the j’th peer the sharesRi,j,p for all the price points p ∈ [1 . . P ]. 6 Eachpeer j ∈ [1 . .m] thus gets Ri,j,p for every investori ∈ [1 . . n] and every price point p ∈ [1 . . P ]. (Theresolution of the price points p is a parameter that wecan adjust, in our implementation we use reslutionsbetween $1 and $0.01.)

Step 2: summation. Each peer j ∈ [1 . .m] simplyadds up locally its shares (over all investors) for eachprice-point p, obtaining

Vj,p :=∑i

Ri,j,p mod N.

For each price point p, the total demand at p is thussecret-shared linearly among the m peers, namelyVol(p) =

∑j Vj,p (mod N).

Step 3: comparisons. Next, the peers need tofind the largest price p∗ such that Vol(p∗) ≥ S. Re-call that S is a known quantity and all the Vol(p)values are shared additively among them.7 For that,the peers conduct a binary-search over the differentprice-points p ∈ [1 . . P ]. Importantly, in our settingthere is no need to hide the intermediate comparisonresults of the binary-search, as they do not revealanything more than can be deduced from the finalclearing price p∗. (In particular they do not revealthe values Vol(p).) Thus, at each pivot-point p of thebinary-search, the peers will run a secure-MPC pro-tocol to compare Vol(p) to S, recovering the compar-ison result in the clear, and then continue to the nextpivot point, until they reach the clearing price p∗.

The comparison protocol. The comparison pro-tocol itself is essentially just the classical GMW

6In our setting, this is done by posting to the ledger anencryption of these Ri,j,p’s under a key known to peer j.

7Essentially the same protocol can be used even when S issecret-shared among the peers rather than being public. Butin our case it is publicly known.

protocol [7], applied to the comparison-to-S func-tion. But GMW requires as input the mod-2 shar-ing of the individual bits. Namely, before we canuse the GMW protocol to compare the k-bit inte-ger X = Vol(p) =

∑k−1`=0 X` · 2` to S, we need the

peers j ∈ [1 . .m] to hold shares Aj,` ∈ {0, 1}, suchthat X` = A1,` ⊕ · · · ⊕Am,` for all ` = 0, . . . , k − 1.

As described above, however, the peers insteadhold integers Vj,p ∈ [0 . . N − 1] such that Vol(p) =∑

j Vj,p (mod N). Hence, before running each com-parison protocol, we must first run a sub-protocol toconvert the mod-N shares Vj,p’s to mod-2 shares ofthe bits Aj,`,p’s. We now show a novel way of per-forming this task, where most of the expensive partis shifted to a pre-computation phase (aided by thefact that the modulus N that we use is a power oftwo, N = 2k).

Fix a particular pivot p, and from now on we dropthe p subscript, writing Vj instead of Vj,p, etc. Wealso denote X = Vol(p) where X is a k-bit inte-ger. In an offline pre-computation phase, each peerj chooses a random number Aj ∈ [0 . . N − 1], andlet Aj,0, . . . , Aj,k−1 be its binary representation (i.e.,

Aj =∑k−1

`=0 Aj,` · 2`). The peers then run a classicalGMW protocol, to compute a binary secret sharing ofthe sum B =

∑mj=1 Aj mod N . Since N is a power

of two, then the reduction modulo N is done sim-ply by ignoring the high order bits of B. At the endof this GMW protocol, the peers will have a mod-2sharing of the bits of B, namely each peer j will haveshares Bj,0, ..., Bj,k−1, such that

k−1∑`=0

2` ·( m⊕j=1

Bj,`

)= B =

( m∑j=1

Aj

)mod N. (2)

Note that the Aj ’s are completely independent of theshares Vj that we will later want to convert, hencethis computation can be done off line, before the Vj ’sare known.

In the online phase, once each peer j computedits share Vj (by summing as above), it locally com-putes the k-bit difference Dj := Vj − Aj mod N ,and just broadcasts Dj to all the other peers. (Nosecret-sharing required here – see below for why thisis secure.) Each peer j, having received the dif-ferences Dj′ from all the peers j′ ∈ [1 . .m] (in-

10

cluding its own), locally compute the number ∆ :=(∑

j Dj)− S mod N , and we have

∆ =∑j

(Vj −Aj

)− S =

(∑j

Vj

)−(∑

j

Aj

)− S

= X − S −B (mod N).

In other words, we have ∆ + B = X − S (mod N),where the peers all know ∆ in the clear, and they havemod-2 secret sharing of the bits of B. The peers nowrun a classical GMW protocol to determine the high-order (k−1)-th bit of the sum of ∆+B, and we claimthat this bit is exactly the boolean value (S > X).

To prove this claim, recall that we have ∆ + B =X − S (mod N), and we know that X = Vol(p) (atthe current pivot p) and the number of shares S areboth smaller than N/2 (and N is a power of two).We prove that S > X iff the (k − 1)-th bit of ∆ + Bis zero.

First, suppose that S ≤ X, then 0 ≤ X − S ≤X < N/2, and hence also (∆ +B mod N) < N/2, sothe (k− 1)-th bit bit of (∆ + B mod N) is zero. ButN = 2k, so it must be that the (k−1)-th bit of ∆+Bis zero even without the mod-N reduction. In theother direction, if S > X then N > (X−S mod N) =X−S+N ≥ N−S > 2k−1. Hence, (∆+B mod N) >2k−1, so the (k − 1)-th bit of (∆ + B mod N) is one,and therefore so is the (k−1)-th bit of ∆+B withoutthe mod-N reduction. �

Epilogue: allocations. After the clearing price isdetermined, the peers still need to compute alloca-tions, i.e., how many shares to sell to each investor.For this, they recover in the clear the total requestedvolume at the clearing price, Vol(p∗). the numberof shares sold to each investor i is set at alloci :=orderi(p

∗) · S/Vol(p∗) (with S the number of avail-able shares). Thus, the total number of shares sold is∑

i orderi(p∗) · S/Vol(p∗) = Vol(p∗) · S/Vol(p∗) = S,

as needed.Note that by construction we have Vol(p∗) ≥ S, so

investors get at most what they asked for at this pricepoint. We typically expects Vol(p∗) = S (so investorsget exactly what they asked for), since for any largerprice p > p∗ we have Vol(p) < S. But this is notguaranteed, and it could happen that Vol(p∗) > S.

We also note that revealing Vol(p∗) is not a securityproblem, since every investor (with alloci(p

∗) > 0)can deduce it just from its own input and output,using Vol(p∗) = S · orderi(p∗)/alloci.

4.3 Security of this Protocol

We now sketch the proof that the protocol is secure inthe semi-honest model. (A complete proof is deferredto the long version of this report.) We need to showthat the view of each peer (or even small collusion ofupto m − 1 peers) yields no more information thancan be deduced from the inputs and outputs of thecomputation alone. First, by the very straightfor-ward description of the additive secret-sharing, theview of any m − 1 peers is random and indepen-dent of the actual orders orderi(p) of the i-th investor.Similar, randomness guarantees hold for other secret-sharings in the protocol, e.g. the secret-sharing ofB =

∑j Aj . The only other part in the protocol

which does not use a classical GMW protocol is therevealing of Dj = Vj −Aj mod N by each peer j.

Recall, Vj is the sum of secret shares of peer j, andthis peer blinds the value Vj by the random Aj before“revealing it” to the other peers. But recall that Aj

is completely random, and the security of the GMWprotocol implies that the view of the other peers inthe protocol for computing the sum B =

∑j Aj does

not reveal anything (computationally) on Aj . HenceAj is still random for the other peers, and thereforerevealing Dj = Vj −Aj mod N does not compromisethe secrecy of Vj .

5 Evaluation

In this section, we evaluate the performance of ourblockchain based IPO trading application. We runour test on a machine with Intel i7 6567U CPU at3.30GHz, 16GB memory, and 500GB SSD disk. Thesoftware environment included Ubuntu 16.04 withLinux kernel 4.15.0 as the operating system, and ourcustomized Hyperledger Fabric v1.1 with point-to-point channels and private data. In all of our exper-iments we ran Fabric with four organizations, eachhaving a single peer (and every peer establishes three

11

point-to-point channels to the others). We vary thenumber of price points in the orders from 100 to40,000.

Figure 6: Elapsed and CPU time of running the IPOtrading application on blockchain using MPC.

In Fig. 6 we show the total elapsed time of runningthe MPC protocol from Section 4 over Fabric, as wellas the CPU time (ignoring communication). The fig-ures describe two different instances of the protocolfrom Section 4, one using binary search to find theclearing price (tAry=2) and the other using an 8-arysearch (tAry=8). As we can see the difference be-tween these variants is not large. When tAry is 8,the total time for running the protocol ranges from 8seconds for 100 price points, to 23 seconds for 40000price points (hence the time grows sub-linearly withthe number of points).

In these figures we also report separately the run-ning times of the offline vs. online phases, noticethat almost all the time is spent during the offlinephase. (Even though in our specific implementationwe run both phases during endorsement, it is possiblein principle to run the offline phase earlier, and thenexecute only the online phase during endorsement.)

Comparing the CPU time to the elapsed time,

shows that almost 90% of the protocol time is spenton communication. This is due to the relatively highbandwidth required, and to the fact that our cur-rent implementation of communication channels overFabric is far from being optimized. (This is an im-portant future-work item.) We note that, when tAryis 8, as the number of price points increases from 100to 40000, the total data transferred by the chaincodecontainers grows from 9.5MB to 98.5MB, which is asub-linear growth.

6 Conclusions and FutureWork

In this work we designed and implemented theclearing price mechanism for IPOs using secure-computation over the Hyperledger Fabric blockchainarchitecture. This work involved both a new crypto-graphic design for an efficient protocol to determinethe clearing price, and a significant integration effortto be able to run this protocol over Fabric. While ourdesign is more than fast enough for the IPO applica-tion, there is still a lot of room for optimization. Foran example, sending messages through CommSCC isan overhead that could be mitigated if the chaincodehad a native API to send messages to executions tak-ing place on other peers.

References

[1] E. Androulaki, A. Barger, V. Bortnikov,C. Cachin, K. Christidis, A. D. Caro,D. Enyeart, C. Ferris, G. Laventman,Y. Manevich, S. Muralidharan, C. Murthy,B. Nguyen, M. Sethi, G. Singh, K. Smith,A. Sorniotti, C. Stathakopoulou, M. Vukolic,S. W. Cocco, and J. Yellick. Hyperledger fabric:a distributed operating system for permissionedblockchains. In R. Oliveira, P. Felber, andY. C. Hu, editors, Proceedings of the ThirteenthEuroSys Conference, EuroSys 2018, Porto,Portugal, April 23-26, 2018, pages 30:1–30:15.ACM, 2018.

12

[2] S. Benediktsdottir. An empirical analysis of spe-cialist trading behavior ar the new york stock ex-change. FRB International Finance DiscussionPaper (876), 2006.

[3] F. Benhamouda, S. Halevi, and T. Halevi. Sup-porting private data on hyperledger fabric withsecure multiparty computation. In 2018 IEEEInternational Conference on Cloud Engineering(IC2E), pages 357–363. IEEE, 2018. Long ver-sion available from https://shaih.github.io/

pubs/bhh18.html.

[4] P. Bogetoft, D. L. Christensen, I. Damgard,M. Geisler, T. Jakobsen, M. Krøigaard, J. D.Nielsen, J. B. Nielsen, K. Nielsen, J. Pagter,M. Schwartzbach, and T. Toft. Secure multi-party computation goes live. In R. Dingledineand P. Golle, editors, Financial Cryptographyand Data Security, pages 325–343, Berlin, Hei-delberg, 2009. Springer Berlin Heidelberg. Longversion at https://ia.cr/2008/068.

[5] E. Cecchetti, F. Zhang, Y. Ji, A. E. Kosba,A. Juels, and E. Shi. Solidus: Confidential dis-tributed ledger transactions via PVORM. InB. M. Thuraisingham, D. Evans, T. Malkin, andD. Xu, editors, Proceedings of the 2017 ACMSIGSAC Conference on Computer and Commu-nications Security, CCS 2017, Dallas, TX, USA,October 30 - November 03, 2017, pages 701–717.ACM, 2017.

[6] S. G. Choi, K.-W. Hwang, J. Katz, T. Malkin,and D. Rubenstein. Secure multi-party compu-tation of Boolean circuits with applications toprivacy in on-line marketplaces. In O. Dunkel-man, editor, CT-RSA 2012, volume 7178 ofLNCS, pages 416–432. Springer, Heidelberg,Feb. / Mar. 2012.

[7] O. Goldreich, S. Micali, and A. Wigderson. Howto play any mental game or A completeness the-orem for protocols with honest majority. InA. Aho, editor, 19th ACM STOC, pages 218–229. ACM Press, May 1987.

[8] S. Goldwasser, S. Micali, and C. Rackoff. Theknowledge complexity of interactive proof sys-tems. SIAM Journal on Computing, 18(1):186–208, 1989.

[9] C. S. Jutla. Upending stock market structure us-ing secure multi-party computation. CryptologyePrint archive: Report 2015/550, 2015.

[10] A. E. Kosba, A. Miller, E. Shi, Z. Wen, andC. Papamanthou. Hawk: The blockchain modelof cryptography and privacy-preserving smartcontracts. In 2016 IEEE Symposium on Secu-rity and Privacy, pages 839–858. IEEE Com-puter Society Press, May 2016.

[11] D. C. Sanchez. Raziel: Private and verifiablesmart contracts on blockchains. CryptologyePrint Archive, Report 2017/878, 2017. https:

//eprint.iacr.org/2017/878.

[12] Swig. http://www.swig.org/, 2018.

[13] D. Tapscott and A. Tapscott. Blockchain Rev-olution: How the Technology Behind Bitcoin IsChanging Money, Business, and the World. Pen-guin Books Canada, 2018.

[14] A. van Wirdum. “confidential assets”brings privacy to all blockchain as-sets: Blockstream. Bitcoin Magazine,https://bitcoinmagazine.com/articles/

confidential-assets-brings-privacy-all-blockchain-assets-blockstream/,April 2017.

[15] A. C.-C. Yao. How to generate and exchange se-crets (extended abstract). In 27th FOCS, pages162–167. IEEE Computer Society Press, 1986.

[16] Zcash - all coins are created equal. https://z.

cash/, 2016. Accessed Dec 2017.

[17] R. Zou. Tangrum: A next-generationdecentralized computation plat-form. https://medium.com/tangrum/

tangrum-a-next-generation-decentralized-computational-platform-e6851c85ebb1,2018. Accessed August 14, 2018.

13

[18] G. Zyskind, O. Nathan, and A. Pentland. De-centralizing privacy: Using blockchain to protectpersonal data. In IEEE Symposium on Securityand Privacy Workshops, pages 180–184. IEEEComputer Society, 2015.

[19] G. Zyskind, O. Nathan, and A. Pent-land. Enigma: Decentralized computationplatform with guaranteed privacy. CoRR,abs/1506.03471, 2015.

14